Несоответствие сборки несмотря на перенаправление сборки и загрузку правильной версии

Мое консольное приложение использует System.Net.Http.Formatting v5.1.0.0, которое зависит от Newtonsoft.Json v4.5.0.0. Мое приложение, однако, включает v6.0.0.0 из Newtonsoft.Json (по другим причинам).

Чтобы заставить System.Net.Http.Formatting использовать новую версию Newtonsoft.Json, я добавил перенаправление сборки в App.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
...
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Тем не менее я получаю следующее исключение:

A first chance exception of type 'System.IO.FileLoadException' occurred in System.Net.Http.Formatting.dll

Additional information: Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Журнал Fusion показывает, что загружена правильная сборка, но она не работает из-за несоответствия:

*** Assembly Binder Log Entry  (2014.08.10. @ 13:13:25) ***

The operation failed.
Bind result: hr = 0x80131040. No description available.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  D:\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
 (Fully-specified)
LOG: Appbase = file:///D:/ConsoleApplication1/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = ConsoleApplication1.exe
Calling assembly : System.Net.Http.Formatting, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///D:/ConsoleApplication1/bin/Debug/Newtonsoft.Json.DLL.
LOG: Assembly download was successful. Attempting setup of file: D:\ConsoleApplication1\bin\Debug\Newtonsoft.Json.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Что я могу сделать, чтобы устранить это несоответствие? Заранее спасибо.

Решение

Там не было ничего плохого с перенаправлением. Единственная подсказка заключалась в том, что он как-то даже не был применен, хотя, казалось бы, все работало, как ожидалось (обратите внимание, что журнал даже показывает, что загружен правильный файл конфигурации). Проблема заключалась в том, что это было объявление в разделе assemblyBinding для другой проблемы сборки:

<qualifyAssembly partialName="log4net" fullName="log4net, 1.2.13.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a" />

Эта строка решила другую проблему, но каким-то образом сломала перенаправление Json. Я не знаю почему: декларация qualifyAssembly, предположительно, тоже правильная.

Тем не менее удаление этого объявления заставило сборку перенаправить работу...

2 ответа

Решение

Там нет никаких доказательств того, что ваш <bindingRedirect> в силе. Тебе следует увидеть:

LOG: Redirect found in application configuration file: 4.5.0.0 redirected to 6.0.0.0.
LOG: Post-policy reference: Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed

В вашем вопросе нет панировочных сухарей, но все, что вы отредактировали, оказалось не D:\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe.Config. Нечетная буква диска. Остерегайтесь проекта, в котором уже есть элемент проекта App.config, и вы добавляете App1.config. Что-то вроде того.

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

Недавно мы столкнулись с этим и обнаружили, что причиной является нарушение схемы XML в файле app.config, вызванное неправильным автоматическим слиянием, например

<dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
        <assemblyIdentity name="Microsoft.Extensions.FileProviders.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.1.1.0" newVersion="1.1.1.0" />
</dependentAssembly>

Мы не заметили проблему в файле, так как он все еще технически допустим, а парсер Visual Studio никогда не жаловался.

Однако подпрограмма связывания во время выполнения отказалась применять какие-либо перенаправления привязки (даже те, которые указаны за пределами поврежденного раздела). Кроме того, как упоминалось выше, в журналах Fusion нет указаний на то, что во время выполнения не удалось проанализировать файл конфигурации. Он видит правильные DLL-файлы и расположение файла конфигурации, но все еще терпит неудачу с незначительным несоответствием версий, как будто никогда не применялось никакого перенаправления.

TL; DR - если вы получаете такое поведение, убедитесь, что ваш XML-файл конфигурации на 100% совершенен, и не верьте, что волнистые линии в VS выявят все возможные проблемы.

Другие вопросы по тегам