Using different versions of DLL in one application

4
votes

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?

2
c#silverlightdllversion
This doesn't make much sense. WCF runs on a different runtime engine than Silverlight. – Jeff Yates
Also, the Silverlight runs on the client and the WCF on the server. I would assume this error relates to the WCF server portion and therefore is unrelated to Silverlight unless your service contract happens to persist a strongly typed value or set of values that cannot be recreated in WCF. In such cases, you should change your contract to contain types supported properly at both sides of the service. – Jeff Yates

2 Answers

2
votes

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

2
votes

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.