Смешивание специфичной для Silverlight System.Xml.Linq dll с не Silverlight System.Xml.Linq dll

Question

У меня есть слой логики, который ссылается на dll System.Xml.Linq в Silverlight и графический интерфейс пользователя в WPF (следовательно, использующий не-Silverlight System.Xml.Linq dll).Когда я пытаюсь передать XElement из проекта GUI методу в проекте Logic, я получаю (в основном) ошибки «XElement не типа XElement».Ситуация усложняется тем, что я не могу отредактировать проект слоя логики.

Не-Silverlight DLL находится по адресу: C: \ Program Files (x86) \ Справочные сборки \ Microsoft \ Framework \ v3.5 \ System.Xml.Linq.dll

Библиотека DLL Silverlight находится по адресу: C: \ Program Files (x86) \ Microsoft SDKs \ Silverlight \ v3.0 \ Libraries \ Client \ System.Xml.Linq.dll

Я новичок в C #, но я уверен, что моя проблема в том, что я обращаюсь к различным библиотекам DLL для доступа к пространству имен System.Xml.Linq.Я попытался заменить не-Silverlight System.Xml.Linq.dll на Silverlight's System.Xml.Linq.dll, но получил ошибки сборки.

Есть ли способ решить эту проблему, исключив мой графический интерфейс WPFпроект и создание проекта Silverlight?

Answer 1

Решение состоит в том, чтобы иметь две версии вашего логического проекта. Один из них ссылается на библиотеки .NET 3.5, а другой - на библиотеки Silverlight. Оба проекта имеют общий набор файлов кода.

Следовательно, вы получаете сборку для WPF и сборку для Silverlight. Если вам нужно изменить код логики, вы можете сделать это один раз, а затем пересобрать решение, которое создаст обе версии библиотеки.

По умолчанию в проекте библиотеки Silverlight уже имеется символ условной компиляции «SILVERLIGHT». Следовательно, если ваш логический код может иметь дело с различиями между библиотеками .NET 3.5 и silverlight, вы можете использовать условную компиляцию для их обхода.

Answer 2

Silverlight и WPF используют принципиально разные фреймворки.Они не совместимы.Многие фундаментальные рамки идентичны между ними, но на самом деле это не одно и то же.

Совместное использование кода в разных проектах, как предложено выше, вероятно, является лучшим решением, но будьте осторожны с условной компиляцией.Часто это приводит к большой сложности.Подходы, такие как шаблон декоратора с внедрением зависимостей, могут быть более уместными, чтобы скрыть различия.

Редактировать: Удалена неверная информация о профиле клиента и Silverlight.

Answer 3

Можете ли вы уточнить "полученные ошибки сборки"? Вы могли бы ссылаться на оба с помощью extern alias, но это сложно и запутанно. Оглядываясь назад, возможно, размещение этой зависимости в API было ошибкой. В качестве альтернативы: вы можете перестроить логическую DLL для целевой платформы?