Проблемы бинарной совместимости системы плагинов C # - PullRequest
Новая
       26

Проблемы бинарной совместимости системы плагинов C #

3 голосов
/ 23 августа 2011

Я внедрил систему плагинов в .NET.Базовая библиотека реализует базовые классы и интерфейсы, предоставляемые подключаемым модулям, библиотеки подключаемых модулей связывают базовую библиотеку для использования предоставляемых классов и интерфейсов.

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

 "Could not load file or assembly 'BaseLibrary, Version=0.0.1.68, Culture=neutral, PublicKeyToken=7b445b12e635292c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"

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

Если есть какой-либо метод для "ослабления" двоичного сопоставления?

Возможно ли, что информация о сборке базовой библиотеки (цитируется ниже)) может быть причиной проблемы? 

 [assembly: AssemblyVersion("0.0.1.*")]

Я забыл упомянуть, что сборки подписаны.

Сборки загружаются с использованием следующей процедуры 

Assembly hLibrary = Assembly.LoadFile(pPath);
Type plugImageCodecFactoryType = hLibrary.GetType("Derm.ImageCodecPluginFactory", true, false);
object plugImageCodecFactory = Activator.CreateInstance(plugImageCodecFactoryType);
object plugInstance;

MethodInfo plugFactoryCreate = plugImageCodecFactoryType.GetMethod("CreatePlugin", BindingFlags.Instance|BindingFlags.Public);

plugInstance = plugFactoryCreate.Invoke(plugImageCodecFactory, null);

if (plugInstance is IImageCodecPlugin)
    RegisterPlugin((IImageCodecPlugin)plugInstance);

Ответы [ 3 ]

4 голосов
/ 23 августа 2011

Прочитайте эти вопросы и ответы для более подробного обсуждения использования AssemblyVersion vs AssemblyFileVersion.

Игнорирование номеров сборок при обращении к DLL

Различия между AssemblyVersion и AssemblyFileVersion

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

Для незначительных изменений вы можете использовать AssemblyFileVersion, чтобы отмечать различия.

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

1 голос
/ 23 августа 2011

Если вы используете Visual Studio, посмотрите на ссылки в одном из проектов, который является плагином.Когда вы смотрите на свойства для ссылки на вашу базовую библиотеку, для чего установлен флаг SpecificVersion?Попробуйте установить его на False и посмотрите, будет ли это иметь значение.

Обратите внимание, что если ваш проект использует ссылку на проект, а не прямую ссылку на скомпилированную DLL, этот флаг не будет присутствовать.В этом случае вам либо нужно использовать фиксированный номер ревизии в базовой библиотеке, как вы пытались, либо вам следует переключиться на использование прямой ссылки на DLL, чтобы вы могли изменить свойство SpecificVersion.

0 голосов
/ 23 августа 2011

Для меня здесь нет ничего общего с плагинами, так как ошибка компилятора говорит о базовой библиотеке, и, учитывая, что вы реализовали базовую архитектуру плагинов, плагины должны быть полностью развернуты и загружены лениво.Так что даже если есть проблема с загрузкой плагина, вы встретитесь во время выполнения, а не во время компиляции.

Так что для меня причина - ваша версия сборки.

С уважением.

...