Смешивание Silverlight-Specific System.Xml.Linq dll с Non-Silverlight System.Xml.Linq dll

Question

У меня есть логический уровень, который ссылается на DLL Silverlight System.Xml.Linq и графический интерфейс, который находится в 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

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

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

Есть ли способ разрешить это, если не выполнить мой проект WPF GUI и создать проект Silverlight?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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