Как разрешить .NET Dll Hell?

Как исправить?

У меня есть 2 сторонних сборки, в которых используется NewtonSoftJson.dll. Улов - один из них использует старшую 3.x.x, а другую - 4.5.x. Поэтому во время выполнения по меньшей мере одна из двух сборок жалуется на другую.

Как я могу это решить? Я мог бы настроить службы, но коды и среды в настоящее время не настроены таким образом. Это также слишком много рефакторинга, чем это можно сделать безопасно за заданный промежуток времени.

Ответы

Ответ 1

У меня возникла проблема с Newtonsoft и другой сторонней библиотекой. Проблема с Newtonsoft v3.x и v4.x заключается в том, что в новой библиотеке теперь есть токен открытого ключа. Это сделало решение перенаправления сборки бесполезным; но это совершенно правильное решение для большинства других случаев.

Я закончил переориентацию библиотеки сторонних разработчиков. Если у вас есть доступ к исходному коду сторонней библиотеки, вы всегда можете перестроить библиотеку, используя новую версию Newtonsoft DLL. Возможно, вам придется внести незначительные изменения, если какая-либо из сигнатур метода изменилась.

Ответ 2

В статье Microsoft "" Перенаправление версий сборки" сказано следующее:

В следующем примере показано, как перенаправить одну версию myAssembly к другому, и отключите политику издателя для mySecondAssembly.

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="myAssembly"
          publicKeyToken="32ab4ba45e0a69a1"
          culture="en-us" />
        <!-- Assembly versions can be redirected in application, 
          publisher policy, or machine configuration files. -->
        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
      <assemblyIdentity name="mySecondAssembly"
        publicKeyToken="32ab4ba45e0a69a1"
        culture="en-us" />
        <!-- Publisher policy can be set only in the application 
          configuration file. -->
        <publisherPolicy apply="no" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Ответ 3

Обычно вы разрешаете эту конфигурацию в своем приложении/веб-конфигурации. Вы можете использовать элемент зондирования для указания частного пути и поместить две версии в отдельные папки:

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin2\subbin;bin3"/>
      </assemblyBinding>
   </runtime>
</configuration>

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

Ответ 4

Заканчивается использование декомпилятора, добавляет проект в решение, ссылается на новые DLL, исправляет ошибки и перекомпилирует, указывает на недавно добавленный проект.

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