Как разрешить конфликтующие сборки в.Net?

Question

В моем веб-приложении я использую NHibernate.dll. Это зависит от следующей сборки.

'Antlr3.Runtime, версия =3.1.0.39271, культура = нейтральная, PublicKeyToken=3a9cab8f8d22bfb7'

Теперь в том же проекте для другого требования я должен представить Antlr3.StringTemplate.dll. Который имеет зависимость от другой версии вышеупомянутой сборки.

Если я использую версию Antlr3.Runtime.dll, которая удовлетворяет NHibernate, Antlr3.StringTemplate начинает жаловаться и наоборот.

Как разрешить такую ​​ситуацию?

Answer 1

Возможно, вы могли бы использовать AssemblyBinding в вашем файле web.config, чтобы перенаправить вашу последнюю версию на старую версию.

Пример:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="NHibernate" publicKeyToken="aa95f207798dfdb4"/>
            <bindingRedirect oldVersion="2.1.0.4000" newVersion="2.1.2.4000"/>
        </dependentAssembly>            
    </assemblyBinding>
</runtime>

Это идет прямо под <configuration> узел в вашем web.config.

Вы можете прочитать об этом здесь: http://msdn.microsoft.com/en-us/library/2fc472t2%28VS.71%29.aspx

Answer 2

Простейшей вещью было бы перекомпилировать обе версии для одной и той же версии. Или вы можете удалить спецификацию версии из ссылки (и установить для конкретной версии значение false).

Answer 3

У меня такая же проблема.

сработало ли для вас связывание

Я попробовал это так, но ничего не изменилось:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="Antlr3.Runtime" publicKeyToken="3a9cab8f8d22bfb7" culture="neutral" />
            <bindingRedirect oldVersion="*" newVersion="3.1.3.6002" />
            <publisherPolicy apply="no"/>
        </dependentAssembly>
    </assemblyBinding>

Появилась та же ошибка.

Поэтому я решил пойти с решением добавить старую версию Antlr3.Runtime сборки в gac. Теперь это работает отлично.

Answer 4

Мы должны были сделать то, что предлагает Джим Лэмб. Мы создали локальные версии всех наших "сторонних библиотек" (как мы их назвали), нацеливаясь на строгие имена и явные зависимости (в отличие от того, что вы можете получить, загрузив dll, которая зависит от другой). Мы поместили эти локальные сборки в наш репозиторий (Subversion). Затем мы поместили получившиеся сборки в папку "Dependencies/lib" в корне каждого из наших проектов, которые зависели от этих сборок. Это позволило нам добавить их в качестве ссылок VS, используя возможности относительного определения пути.