Geek Answers Handbook

Using different versions of DLL in one application

I have a Silverlight class library that is used by both the Silverlight application and the regular C # WCF service.

The Silverlight application calls the WCF service to read / write some data. They use a common library to control the transmitted data.

Everything compiles fine, but when we run the application, webservice produces the following error when calling the silverlight library:

"Failed to 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 specified file."

This is because the silverlight class library references v2.0.5 System.Xml, but the WCF service refers to v3.5 System.Xml.

Is there a way to reference both versions and not get an error?

+4
source share
2 answers

If you have a source for a shared library, the best solution would be to have 3 projects, once for SL, one for WCF and one for the source of the shared library. You can then link to the source files from the shared library in the SL and WCF projects using the visual studio add as link option. The source files can then be compiled against the correct versions of the .Net library. The best part is that the source is a reference instance when you make changes to the shared library and the SL and WCF projects are updated without any duplication.

We used this approach in our product and it works very well.

NTN

+2
source

No, this is not supported in the CLR (without a big hack). The reason is that this is due to a fundamental limitation of the CLR. Namely, that one and only one mscorlib can be loaded into the CLR instance.

If you have 2 versions of System.Xml.dll, the link will link to two different versions of mscorlib. This is especially true for Silverlight and non-Silverlight projects, which have radically different mscorlib and BCL DLLs. Therefore, when you try to load the second System.Xml DLL, it will eventually try to load another mscorlib, which will fail.

The reason I added “no major hack” is a reservation - a mandatory redirect. I'm sure there is some nice attachment that you can insert in app.config that redirects Silverlight System.Xml to the whole System.Xml to get a functional load. However, this will almost certainly lead to worse errors in the future as the program executes.

+2
source

More articles:


All Articles