CODEWITHSUNDEEP
c#silverlightvisual-studio-2010xml-serializationsilverlight-5.0
stech
stech

Reputation: 745

could not load system.xml with silverlight class library

I have 3 projects - silverlight app A and 2 silverlight class libraries B,C. My serialization logic is in project C, Method CallSer(). If the routine from B calls CallSer(), everything works fine. But if routine from C calls CallSer(), it gives the below error. I have tried setting Copy Local property but it's not helped (I am seeing the assemblies getting copied to the debug folder when Copy Local = True). This seems to be surprising, any one has ideas on how to resolve this? Thanks.

{System.IO.FileNotFoundException: Could not load file or assembly 'System.Xml, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified. File name: 'System.Xml, Version=5.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'}

Update: I did a little more analysis and found the call to CallSer() is actually from another .NET class library D. So call stack shows is D -> C -> CallSer(). I am not sure what difference this can make as long as I have System.Xml.Serialization reference to C. Also, I don't see System.Xml.Serialization listed in Add Reference option for D? Why is that so?

Update: Looks like XmlSerializer is getting confused as to which reference to load.That's because Silverlight has XmlSerializer defined inside System.Xml.Serialization.dll assembly and .NET framework has it in System.Xml.dll. My project D has reference to System.Xml and C has System.Xml and System.Xml.Serialization. How do I make sure C always references Silverlight version of dlls?

Upvotes: 2

Views: 3212

Answers (2)

Eldritch Conundrum
Eldritch Conundrum

Reputation: 8732

I had the same problem with Xml.Writer.

I worked around it by sharing my source code file between my silverlight project and my non-silverlight project, using 'Add as Link' in Visual Studio. I also had to use #ifdef SILVERLIGHT to have a separate namespace.

Lloyd's Portable Class Library approach seems cleaner but I didn't have time to try it.

Upvotes: 0

Lloyd
Lloyd

Reputation: 2942

I came across the same issue trying to run unit tests, the problem is that if the code that is calling the Silverlight Class Library is built against the "desktop" .Net Framework you will get the conflict as it will not be able to load the Silverlight version of the dll, only the Silverlight runtime can load dll's built against the Silverlight CLR/BCL.

Take a look at creating a Portable Class Library and the Portable Library Tool

Upvotes: 2

Related Questions