Ссылка System.Net.Http NuGet 4.3.0 создает ссылку System.IO.FileLoadException на ссылку System.Diagnostics.DiagnosticSource ver 4.0.0.0.

Описание проблемы:

Проект общей библиотеки "shared.dll" ссылается на пакет 4.3.0 System.Net.Http NuGet. Приложение, которое ссылается на "shared.dll" не работает с

System.IO.FileLoadException

Не удалось загрузить файл или сборку 'System.Diagnostics.DiagnosticSource, версия =4.0.0.0, Culture= нейтральный, PublicKeyToken=cc7b13ffcd2ddd51' или одну из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

в System.Net.Http.WinHttpHandler.SendAsync(...)

После изучения этой проблемы мы пришли к следующей причине вышеуказанного сбоя:

  • На странице информации о пакете для System.Net.Http v 4.3.0 указывается зависимость от https://www.nuget.org/packages/System.Diagnostics.DiagnosticSource/ или выше. Этот пакет автоматически загружается при ссылке на System.Net.Http v 4.3.0 из проекта.
  • Пакет NuGet для System.Net.Http v 4.3.0 фактически включает System.Net.Http.dll v 4.1.1.0 (по состоянию на 8 января 2017 года).
  • Пакет NuGet System.Diagnostics.DiagnosticSource v 4.3.0 фактически включает System.Diagnostics.DiagnosticSource v 4.0.1.0 (по состоянию на 8 января 2017 года).
  • System.Net.Http ver 4.1.1.0 ссылается на System.Diagnostics.DiagnosticSource v. 4.0.0.0 введите описание изображения здесь
  • System.Diagnostics.DiagnosticSource v. 4.0.0.0 не является точным соответствием v загруженной dll v 4.0.1.0.
  • Если версия ссылки на библиотеку со строгим именем не совпадает точно, среда выполнения.NET все еще пытается найти указанную сборку. Если не может: генерируется исключение загрузки библиотеки. Также см. Следующее замечание

Есть несколько обходных путей:

  1. Опция app.config: объявлять совместимые версии (как далеко мы должны идти с этим?) с перенаправлением привязки в app.config для любого приложения, ссылающегося на "shared.dll".
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.1.0" newVersion="4.0.1.0" />
  </dependentAssembly>
</assemblyBinding>
  1. Заставить System.Diagnostics.DiagnosticSource.dll к версии 4.0.0.0: добавить ссылку NuGet на System.Diagnostics.DiagnosticSource v. 4.0.0.0 на проекты, ссылающиеся на System.Net.Http, чтобы предотвратить автоматическую загрузку dll версии 4.0.1.0. Эта опция теряет способность автоматически обновлять зависимость NuGet, но делает развертывание приложений без конфигурации.

Однако существует неприятное ощущение, что правильное решение проблемы заключается в устранении вышеупомянутых несоответствий пакетов NuGet владельцами пакетов. После исправления в источнике обходного пути для кода, потребляющего пакет System.Net.Http, не требуется.

Вопросы:

  1. Почему пакет System.Net.Http v 4.3.0 содержит несоответствие System.Net.Http.dll v 4.1.1, в то время как существует более ранняя версия пакета 4.1.1?
  2. Должны ли мы идти вперед с любым из 2 обходных путей, упомянутых выше?
  3. Какой из них лучше?
  4. Или: есть ли другое решение проблемы?
  5. Или: есть ли неизбежное обновление пакетов NuGet, которое исправляет несоответствие?

Благодарю.

Источник

4 ответа

Решение

Я чувствую, что было бы действительно правильно ответить на мой собственный вопрос, потому что 99% ответов уже есть.

Команда разработчиков в github/corefx признала, что решение этой проблемы будет побочным эффектом другого известного исправления проблемы, так как удалена жесткая ссылка на System.Diagnostics.DiagnosticSource.dll из проекта System.Net.Http.

До тех пор: любой из двух предоставленных обходных путей можно использовать в зависимости от личных предпочтений.

Источник

Я решил эту проблему, установив System.Net.Http (версия 4.3.1) из NuGet.

Источник

В моем случае

FileLoadException: не удалось загрузить файл или сборку 'System.Diagnostics.DiagnosticSource, версия =4.0.3.0, культура = нейтральная, Public KeyToken=cc7b13ffcd2ddd51'. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

Началось, когда к проекту Asp.Net Core 2.0 был добавлен пакет Microsoft.AspNetCore.TestHost "2.1.0-preview2-final". Исправление было установить стабильную версию "2.0.2"

Источник

У меня не работали ни перенаправления привязки сборки, ни добавление ссылки на System.Net.Http. Понятия не имею почему. Что в конечном итоге сработало для меня, так это удалить спецификацию версии и указать HintPathнепосредственно в DLL. Итак, я исходил из этого:

      <Reference Include="System.Diagnostics.DiagnosticSource, Version=6.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">

к этому:

      <Reference Include="System.Diagnostics.DiagnosticSource, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Diagnostics.DiagnosticSource.6.0.0\lib\net461\System.Diagnostics.DiagnosticSource.dll</HintPath>
  <Private>True</Private>
</Reference>

и это, кажется, сделало свое дело. Мне не нравится терять прямую ссылку на версию, но, похоже, другого пути не было.

Источник
Другие вопросы по тегам