Как разрешить конфликтующие блоки в .NET?
В моем веб-приложении я использую NHibernate.dll. Это имеет зависимость от следующего блока.
'Antlr3. Время выполнения, Version=3.1.0.39271, Culture=neutral, PublicKeyToken=3a9cab8f8d22bfb7'
Теперь в том же проекте для другого требования я должен представить Antlr3.StringTemplate.dll. Который имеет зависимость от другой версии вышеупомянутого блока.
Если я использую версию Antlr3.Runtime.dll, который удовлетворяет NHibernate, Antlr3. StringTemplate начинает жаловаться и наоборот.
Как разрешить такую ситуацию?
3 ответа
Возможно, вы могли бы использовать 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>
Это находится непосредственно под узлом в вашем web.config.
Вы можете прочитать об этом здесь: http://msdn.microsoft.com/en-us/library/2fc472t2%28VS.71%29.aspx
Самым простым было бы перекомпилировать обе версии для одной и той же версии. Или вы можете удалить спецификацию версии из справочника (и установить для конкретной версии значение false).
Мы должны были сделать то, что предлагает Джим Лэмб. Мы создали локальные версии всех наших «сторонних библиотек» (как мы их назвали), ориентируясь на строгие имена и явные зависимости (в отличие от того, что вы можете получить при загрузке одной DLL, которая зависит от другой). Мы зафиксировали эти локальные сборки в нашем репозитории (Subversion). Затем мы поместили полученные сборки в папку «Dependencies / lib» в корне каждого из наших проектов, которые зависели от этих сборок. Это позволило нам добавить их в качестве ссылок VS, используя его возможности определения относительного пути.