Общие ссылки на DLL в проекте Silverlight

Question

У меня есть общий проект Silverlight.Этот проект проекта, среди прочего, включает в себя константы и статические классы.

Приложение Silverlight у меня есть ссылки на эту общую библиотеку.Кроме того, у меня есть несколько внешних модулей, которые загружаются по требованию (через Prism).Каждый модуль - это собственный файл .Xap, и они тоже ссылаются на общую библиотеку.

Так что теперь каждый Xap в моем приложении silverlight имеет ссылку на Common.dll.Означает ли это, что common.dll загружается каждый раз, когда загружается xap, или это по сути означает, что загружается только common.dll основного приложения?

Главный вопрос, который я получаю, заключается в следующем: если я сделаюизменение кода (исправление ошибки) в common.dll, нужно ли мне выпускать ВСЕ файлы Xap или только главное приложение xap?

Спасибо.

Answer 1

Если вы используете Кэширование сборки во всех проектах, которые ссылаются на общую dll, то вы просто скачаете одну копию в виде собственного zip-файла.Таким образом, все различные файлы XAP будут ссылаться на одну и ту же DLL.В противном случае common.dll будет включено в каждый файл XAP, на который ссылается.

Вам нужно будет создать файл common.extmap.xml для вашего common.dll, который должен находиться в той же папке, откуда указывается dll.

Answer 2

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

Некоторые вещи, которые вы можете сделать:

1. GAC Common.dll в целевой среде. Это позволит вам централизованно управлять версиями этой DLL.
2. Выпускать все при каждом изменении Common.dll (как вы уже упоминали).

Мы выбрали номер 2 (мы рассматриваем наш «Common.dll» как сборку контракта, которая редко изменяется), чтобы сохранить наши развертывания xcopy без изменений.

Номер 1 может иметь больше смысла, если вы ожидаете, что отток кода на Common.dll будет высоким или вы хотите, чтобы графики развертывания модулей были полностью автономными (например, если модули разрабатывались и разворачивались отдельными группами с отдельной сборкой). и исходные хранилища, например).

Редактировать : Похоже, у Silverlight есть что-то, чтобы обеспечить вариант gcopy для подхода GAC. Ответ ChrisF, вероятно, такой же, как и в Silverlight (мы делаем WPF, так что это немного по-другому). Я оставлю это здесь для потомков.