Mixing Silverlight-Specific System.Xml.Linq dll with Non-Silverlight System.Xml.Linq dll

Question

I have a Logic layer that references Silverlight's System.Xml.Linq dll and a GUI that is in WPF (hence using the non-Silverlight System.Xml.Linq dll). When I attempt to pass an XElement from GUI project to a method in the Logic project, I am getting (basically) "XElement is not of type XElement" errors. To complicate matter, I am unable to edit the Logic layer project.

The Non-Silverlight DLL is at: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\System.Xml.Linq.dll

THe Silverlight DLL is at: C:\Program Files (x86)\Microsoft SDKs\Silverlight\v3.0\Libraries\Client\System.Xml.Linq.dll

I am new to C# but I'm fairly sure my issue is that I am referencing different DLL's to access the System.Xml.Linq namespace. I attempted to replace my non-Silverlight System.Xml.Linq.dll with the Silverlight's System.Xml.Linq.dll, but received assembly errors.

Is there any way to resolve this short of scrapping my WPF GUI project and creating a Silverlight project?

Answer 1

The solution is to have two versions your logic project. One that references the .NET 3.5 libraries and the other references the Silverlight libraries. Both projects share a common set of code files.

Hence you get a build for WPF and a build for Silverlight. If you need to change the code of the logic you can make it once and then rebuild the solution which will create both versions of the library.

By default a Silverlight library project has the Conditional compilation symbol of "SILVERLIGHT" already in place. Hence where your logic code may have to deal with differences between .NET 3.5 and silverlight libraries you can use Conditional compilation to work round them.

Answer 2

Can you clarify "received assembly errors"? You might be able to reference both by using extern alias, but this is tricky and confusing. In hindsight, perhaps placing this dependency in the API was an error. Alternatively: can you possibly rebuild the logic dll for the target framework?

Answer 3

Silverlight and WPF use fundamentally different frameworks. They are not compatible. A lot of the fundamental framework is identical between the two, but they are not, in fact, the same thing.

Sharing code in different projects, as suggested above, is likely the best solution, but be careful about the conditional compilation. Often that leads to a lot of complexity. Approaches like a decorator pattern with Dependency Injection might be more appropriate to hide the differences.

Edit: Removed some wrong information about Client Profile vs. Silverlight.