Смена привязки к сборке не работает

Ответ 1

Любая опечатка в конфигурации xml может быть причиной. Погрузчик просто не видит вашу конфигурацию. У меня также был час головной боли, пока я не понял, что ошибка была в символе "=" вместо "-" в имени схемы:

<assemblyBinding xmlns="urn:schemas=microsoft-com:asm.v1">

Просто внимательно проверьте все имена и значения атрибутов. Я думаю, что "PublicKeyToken" должен быть "publicKeyToken"

Это должно работать:

<configuration>
<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.AnalysisServices" publicKeyToken="89845dcd8080cc91" />
            <bindingRedirect oldVersion="10.0.0.0" newVersion="9.0.0.0"/>
        </dependentAssembly>
    </assemblyBinding>
</runtime>
</configuration>

Ответ 2

Убедитесь, что тэг <configuration> имеет атрибут пространства имен. В противном случае тег <assemblyBinding> будет проигнорирован.

Неправильно:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

Справа:

<configuration>

(из fooobar.com/questions/25420/...)

Ответ 3

Я обнаружил, что перенаправление привязки сборки не работает из-за отсутствия пространства имен в элементе assemblyBinding.

Правильный

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="TIBCO.Rendezvous" publicKeyToken="1a696d1f90f6158a"/>
    <bindingRedirect oldVersion="1.0.0.0-1.0.3191.28836" newVersion="1.0.3191.28836"/>
  </dependentAssembly>

некорректный

Примечание отсутствует: xmlns = "urn: schemas-microsoft-com: asm.v1"

<assemblyBinding>
  <dependentAssembly>
    <assemblyIdentity name="TIBCO.Rendezvous" publicKeyToken="1a696d1f90f6158a"/>
    <bindingRedirect oldVersion="1.0.0.0-1.0.3191.28836" newVersion="1.0.3191.28836"/>
  </dependentAssembly>

Ответ 4

в моем случае мне пришлось удалить

appliesTo="v2.0.05727" 

от

<assemblyBinding appliesTo="v2.0.05727" xmlns="urn:schemas-microsoft-com:asm.v1">

Ответ 5

Моя проблема была решена, когда я перевел привязку конфигурации перенаправления к файлу machine.config.

Ответ 6

У меня была аналогичная проблема, когда перемещение bindredirects к Machine.Config было единственным, что сработало. Это не было идеальным решением в моем приложении winform, потому что я распространяю свое приложение на клиентов.

Решение:

Убедитесь, что файл .config находится в каталоге, из которого выполняется ваше приложение. например если ваше AppName - "MyApp", то перенаправление должно быть в файле "MyApp.exe.Config" в каталоге приложения.

Я должен был это сделать, даже если код, использующий сторонние DLL файлы, находится в разных dll в моем решении, и добавление .dll.config не помогло.

Ответ 7

Эксцентричные политики паролей также могут привести к игнорированию элементов assemblyBinding в конфигурации. Такие персонажи, как '&' и '^', по-видимому, не разрешены в файле конфигурации. XML-инструменты в Notepad ++ показали это мне после нескольких часов работы с инструментом просмотра привязки к сборке.

Ответ 8

Если вы установите Visual Studio 2017 без части инструментов разработки ASP.NET, он все равно загрузит веб-проект, скомпилирует и соберет его. Он просто выдаст предупреждения о версиях пакета NuGet, потому что он не знает, что делать с файлом web.config, и поэтому не может видеть перенаправления привязки.

Исправление установки решило мою проблему, но потребовалось много времени, чтобы понять.

Ответ 9

Если это кому-то поможет, я столкнулся с этим, потому что я не ввел полную версию для newVersion. то есть я имел newVersion="3.0.1" вместо newVersion="3.0.1.0"

Ответ 10

Проверьте, если ошибка Явное связывание переадресации на xxx, Culture = neutral, PublicKeyToken = xxx "конфликтует с аутогенерированным переадресацией привязок

появится в окне вывода (оно не появится в окне ошибки)

Ответ 11

Большое спасибо за ответы, особенно от Шрайка. У меня было одно приложение, которое работало в разработке, но не в развернутой версии. Когда я посмотрел более внимательно, у меня было это в производстве, которое НЕ соответствовало разработке:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly xmlns="">
        <assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" />
        <bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

зависимый сборщик xmlns = "" был виновником. Как только я сравнил свой с вашим ответом и исправил это, он работал. Спасибо за помощь

Ответ 12

Еще одно решение для тех, кто тоже борется

Убедитесь, что каждая <dependentAssembly> <assemblyIdentity> имеет только одну <assemblyIdentity> и одну <bindingRedirect>. В моем сценарии у меня было два в одном, что вызывало каскадный сбой нескольких перенаправлений привязки

<dependentAssembly>
        <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />

        <assemblyIdentity name="SimpleInjector" publicKeyToken="984cb50dea722e99" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.4.2.0" newVersion="4.4.2.0" />
</dependentAssembly>

Это означало, что вместо моей привязки SimpleInjector к 4.4.2.0 он привязывался к 5.2.3.0, что привело к ошибке, сообщающей, что он не может правильно привязать System.Web.Mvc, скрывая истинную проблему