Использование различных версий DLL в одном приложении

Question

У меня есть библиотека классов Silverlight, которая используется как приложением Silverlight, так и с обычной службой WCF C#.

Приложение Silverlight вызывает службу WCF для чтения/записи некоторых данных. Они используют общую библиотеку для управления передаваемыми данными.

Все компилируется нормально, но когда мы запустим приложение, то вебсервис выдает следующее сообщение об ошибке, когда вызов SilverLight библиотеки производится:

«Не удалось загрузить файл или сборку«System.Xml, Version = 2.0 .5.0, Culture = neutral, PublicKeyToken = 7cec85d7bea7798e 'или одна из его зависимостей. Система не может найти указанный файл. "

Это потому, что библиотека классов silverlight ссылается на v2.0.5 System.Xml, но служба WCF ссылается на v3.5 System.Xml.

Есть ли способ, которым я могу ссылаться на обе версии и не получить ошибку?

Answer 1

Если у вас есть источник для общей библиотеки, тогда лучший подход состоит в том, чтобы иметь 3 проекта, один раз для SL, один для WCF и один для источника совместно используемой библиотеки. Затем вы можете ссылаться на исходные файлы из общей библиотеки в проектах SL и WCF, используя опцию add-link в visual studio. Исходные файлы затем могут быть скомпилированы против правильных версий библиотеки .Net. Самое приятное в этом - из-за того, что источник является ссылочными копиями, когда вы вносите изменения в общую библиотеку, и проекты SL и WCF обновляются без какого-либо дублирования.

Мы использовали этот подход в нашем продукте, и он работает очень хорошо.

HTH

Answer 2

Нет, это не поддерживается в CLR (без большого взлома). Причина в том, что это связано с фундаментальным ограничением CLR. А именно, что один и только один mscorlib могут быть загружены в экземпляр CLR.

Если у вас есть 2 версии System.Xml.dll, ссылка будет ссылаться на две разные версии mscorlib. Это особенно справедливо для проектов Silverlight и non-Silverlight, которые имеют радикально отличающиеся mscorlib и BCL DLL. Поэтому, когда вы пытаетесь загрузить вторую DLL System.Xml, она в конечном итоге попытается загрузить другой mscorlib, который будет терпеть неудачу.

Причина, по которой я добавил «без серьезного взлома», является обязательным переадресацией. Я уверен, что есть какая-то прекрасная привязанность, которую вы можете вставить в app.config, которая перенаправляет Silverlight System.Xml на весь System.Xml, чтобы получить функциональную загрузку. Однако это почти наверняка приведет к ухудшению ошибок в будущем по мере выполнения программы.