.Net Надстройки и управление версиями - PullRequest
4 голосов
/ 10 июня 2009

Наша надстройка медиацентра поставляется в виде единой библиотеки DLL, которая находится в GAC (mediabrowser.dll), мы позволяем пользователям писать расширения для нашей надстройки, ссылаясь на нашу DLL и получая доступ к предопределенным точкам расширения.

При загрузке мы ищем в каталоге подключаемого модуля, загружаем все сборки в каталоге, ищем в сборках тип, реализующий IPlugin, и выполняем процедуру инициализации на экземпляре плагина. Я знаю, что это не самый надежный дизайн (например: мы можем захотеть взглянуть на изоляцию appdomain для плагина позже), но теперь он работает нормально.

Похоже, что это работает нормально, за исключением одного большого предостережения.

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

Я подумал о нескольких решениях этой проблемы (обратите внимание, сборка в GAC):

  1. Поставьте политику издателя вместе с mediabrowser.dll, которая перенаправит все более ранние совместимые версии mediabrowser.dll в текущую версию (она также должна находиться в GAC).
  2. Отправьте отдельную сборку, которая содержит все фиксированные точки расширения и контракты, будьте особенно осторожны при изменении этой сборки, попросите авторов плагинов связать эту сборку. (но все же посмотрите на использование политик издателя для непрерывных изменений интерфейсов)
  3. Пусть третье лицо беспокоится об этом и использует MEF или какую-то другую среду, которая заботится о подобных вещах.
  4. Подключение AppDomain.CurrentDomain.AssemblyResolve и разрешить более ранние версии сборки в текущей версии. Это будет работать, только если сборка этой конкретной версии отсутствует в GAC.

Существуют ли другие способы решения этой проблемы, которые мне не хватает?

Обновление В итоге я выбрал вариант 4.

1 Ответ

1 голос
/ 15 июня 2009

Я вижу, что вы выбрали ответ, но если вы все еще открыты для идей, есть еще один вариант (тот, который используется в .NET Framework): не увеличивайте версию вашей сборки между сборками (но увеличивайте свою сборку номер сборки).

Это позволит вашей сборке сохранить то же строгое имя, не нарушая совместимость плагинов, и все же позволит вам отличать сборки друг от друга (используя номер сборки сборки).

Вы можете увидеть это в действии в .NET 2.0 до 3.5. Все эти версии используют версию сборки 2.0.50727, но имеют разные версии сборки.

Пока вы не нарушаете свои контракты на интерфейс (что вы никогда не должны делать), такой подход вполне разумен.

...