CODEWITHSUNDEEP
c#silverlightdllversion
Zak
Zak

Reputation: 325

Using different versions of DLL in one application

I have a Silverlight Class Library that is being used by both Silverlight application and a regular C# WCF Service.

The Silverlight application calls the WCF service to read/write some data. They both use the common library to manipulate the data being passed.

Everything compiles fine, but when we run the application, the webservice throws the following error when the call to the silverlight library is made:

"Could not load file or assembly 'System.Xml, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified."

This is because the silverlight class library is referencing v2.0.5 of System.Xml, but the WCF Service is referencing v3.5 of System.Xml.

Is there a way I can reference both versions and not get the error?

Upvotes: 5

Views: 2593

Answers (2)

JaredPar
JaredPar

Reputation: 754545

No this is not supported in the CLR (without a good deal of hacking). The reason why is because of a fundamental limitation of the CLR. Namely that one and only one mscorlib can be loaded into an instance of the CLR.

If you have 2 versions of System.Xml.dll, the will reference 2 different versions of mscorlib. This is especially true for a Silverlight and non-Silverlight project which have radically different mscorlib and BCL DLL's. Therefore when you try to load the second System.Xml DLL, it will eventually try and load the different mscorlib which is bound to fail.

The reason I added the "without a good deal of hacking" caveat is binding redirection. I'm sure there's some lovely binding magic you could insert into app.config which would redirect the Silverlight System.Xml to the full System.Xml to get it to functionally load. However this would almost certainly lead to worse off errors down the road as the program executed.

Upvotes: 2

Andy Britcliffe
Andy Britcliffe

Reputation: 769

Providing you have the source for the common library then the best approach is to have 3 projects, once for SL, one for WCF and one for the shared library source. You then can reference the source files from the shared lib in the SL and WCF projects using visual studio's add as link option. The source files can then be compiled against the correct .Net library versions. The nice thing about this is due to the source being reference copies, when you make changes to the shared lib, both the SL and WCF projects get updated without any duplication.

We've been using this approach in our product and it works very well.

HTH

Upvotes: 2

Related Questions