Не удалось загрузить файл или сборку System.Net.Http, Version = 2.0.0.0 в веб-API MVC4

У меня немного странная проблема.
Я разработал приложение с MVC 4 и новым веб-API, и оно отлично работает локально. Я установил MVC4 на сервер и развернул приложение. Теперь я получаю следующую ошибку:

Не удалось загрузить файл или сборку System.Net.Http, Version = 2.0.0.0, Culture = нейтральный, PublicKeyToken = 31bf3856ad364e35 или одну из их зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

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

Как ни странно, версия System.Net.Http, которая есть у меня локально либо в папке моего пакета, либо в папке ASP.NET MVC 4 \ Assemblies, - 1.0.0.0. Я действительно удалил ссылку на System.Net.Http из своего проекта, но все равно получаю то же сообщение. Я немного смущен тем, откуда он берет ссылку на 2.0.0.0 и почему он будет работать локально, а не на сервере.

Посмотрим на зависимости nuget:

Базовые библиотеки ASP.NET WEb API (бета) зависят от System.Net.Http.Formatting.
И System.Net.Http.Formatting зависит от System.Net.Http.
Думаю, вот откуда это взялось. Но у меня установлена ​​версия 2.0.20126.16343 этого пакета, просто у dll внутри версия 1.0.0.0

Я что-то упускаю?

ОБНОВИТЬ:

Это вспомогательное приложение другого приложения ASP.NET, но другое все еще основано на WebForms. Итак, что-то не так. Но если я сделаю чистку в разделе сборки в web.config, если даже не найдет само приложение.

У меня была такая же проблема с развертыванием моего приложения в appharbor. Проблема в том, что он пока не поддерживает .NET 4.5. Что я сделал.

1. Переключил мой проект на профиль .NET 4.0.
2. Неустановленный пакет NuGet веб-API.
3. Снова установлен пакет NuGet для веб-API (бета).
4. Проверено, что файл .csproj содержит ВСЕ указанные сборки, поэтому он всегда будет брать его из папки Bin, а не из GAC.

У меня была такая же ошибка при развертывании ранее преобразованного (из .NET 4.5 в 4.0) веб-приложения в IIS 6.0.

В разделе времени выполнения web.config я нашел

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>

который я изменил на

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Теперь работает шарм.

Моя работала с:

Обратите внимание на перенаправление с 1-4 на 2.0.

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a"   culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

В папке References вашего проекта должна быть ссылка на эту dll, а версия должна быть 2.0.0.0. Убедитесь, что для этого параметра установлено значение Copy Local = true. А затем убедитесь, что он попал в папку bin вашего серверного приложения.

Это одна из библиотек, которой теперь управляет nuget. Итак, откройте Nuget и убедитесь, что все обновлено. И в каталоге пакетов ваших проектов файл должен быть здесь: \packages\System.Net.Http.2.0.20126.16343\lib\net40

Вы также можете попробовать создать новое приложение MVC4 и посмотреть, отображается ли для него файл.

В моем случае я исправил это намного проще, просто дайте HintPath ссылку на пакет nuget:

     <Reference Include="System.Data.Entity" />
     <Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
     </Reference>
     <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>True</Private>
+      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
     </Reference>
     <Reference Include="System.Numerics" />
     <Reference Include="System.Security" />

В моем случае я непреднамеренно добавил зависимость к System.Net.Http версии 2.1.10.0 через NuGet. Я не мог избавиться от него в диспетчере пакетов NuGet (потому что, похоже, от него зависели другие пакеты). Однако эти пакеты не зависят от этой конкретной версии. Вот что я сделал, чтобы избавиться от него (вместо этого вы также можете использовать консоль NuGet (используя параметр –force):

• Измените версию Microsoft.Net.Http в packages.config с 2.1.10.0 на 2.0.0.0
• Удалите пакет переносимости BCL в диспетчере пакетов NuGet
• Вручную избавьтесь от зависимых библиотек (System.Net.Http. * С версией 2.1.10.0)
• Добавьте ссылку на System.Net.Http 2.0.0.0

В конфигурации файла я удалил зависимую сборку:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

Теперь работает нормально.

Я столкнулся с этой проблемой на тестовом сервере (Windows 2008 R2), который предположительно был «готов» к развертыванию;)

Подсказка заключалась в том, что когда я проверял версии System.net между моей машиной DEV и сервером развертывания, они не совпадали.

Исправлено с помощью следующих шагов:

1. Скачал автономный установщик .NET Framework 4.5 ЗДЕСЬ

2. Запустите установщик на машине развертывания

После установки фреймворка серверу захотелось перезагрузки, так и сделали, и волла! Мы готовы пойти !!

Мы используем VS 2013, создали новый веб-API MVC 4 и столкнулись с проблемой, когда system.net.http.dll не был правильной версией при построении на нашем сервере TeamCity, но он отлично работает на наших локальных машинах разработчика, на которых есть VS 2013. установлен.

Мы окончательно определили проблему.

При создании нового веб-API MVC 4 и выборе фреймворка 4.0 при создании проекта мы обнаружили, что правильная версия пакета NuGet для DLL помещается в: .. \ packages \ Microsoft.Net.Http.2.0.20710.0 \ lib \ net40 \ System.Net.Http.dll

Однако в файле .csproj для этого проекта указано, что путь к этому файлу system.net.http.dll: .. \ packages \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.Http.dll

Таким образом, при попытке сборки происходит сбой на этой разнице путей, но выполняется поиск правильной версии файла платформы в другом месте на компьютере разработчика, но не на нашем сервере сборки TeamCity.

Пока это единственное различие, которое мы обнаружили. Изменение пути в файле .csproj и создание на локальной машине Dev с VS2013 все еще работает.

Проверка этого в системе контроля версий и наличие нашего сервера сборки TeamCity (без локальной установки VS 2013) теперь находит правильную версию .dll в своей папке пакета NuGet для решения и успешно выполняет сборку, а не ищет другую версию system.net.http .dll и поиск более новой версии, которая не соответствует структуре, что вызывает сбои сборки.

Не уверен, что это поможет.

Проверьте путь к файлу проекта для DLL и убедитесь, что он соответствует пути к папке с пакетом для DLL.

Просто упрощаю другие ответы на то, что сработало для меня.

Я пошел к диспетчеру NuGet, удалил соответствующие пакеты (в моем случае «Клиентские библиотеки Microsoft ASP.NET Web API 2.1» и «Json.NET») и переустановил их. Всего несколько кликов.

Закройте проект, откройте его снова. Затем чистое решение + сборка. Работает для меня

Для версии 2.2.15.0 я сделал так:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>

У меня была такая же проблема! Я взглянул на вкладку «Предупреждения» в VS и заметил, что один из моих пакетов nuget КОСВЕННО ссылается на .NETFramework версии 4.5.0.0. Мне пришлось удалить этот пакет, а затем переустановить версию 4.0, но обязательно укажите версии пакета, которые поддерживают 4.0 (я думаю, по умолчанию вернется к 4.5, если вы не укажете при установке пакета). Надеюсь это поможет!

У нас это происходило на сервере после развертывания. Это было вызвано либо:

A) Старые файлы в папке bin все еще валяются, которые следовало удалить.

или

Б) Отсутствие доступа на чтение к папке для пользователя Application Pool Identity.

Другими словами, для нас это было решено путем исправления разрешений для папок для сайта, удаления папки bin и повторного развертывания.

У меня была такая же проблема с Gembox.spreadsheet.dll версии 31.

«Не удалось загрузить файл или сборку GemBox.Spreadsheet, Version = 39.3.30.1095, Culture = нейтральный, PublicKeyToken = b1b72c69714d4847» или одну из его зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040 ) "

Я перепробовал почти все из этих статей, и ни одна из них не сработала. Это просто было исправлено простым шагом.

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

Идите по аналогичной проблеме, и директива, упомянутая во многих комментариях, работала нормально

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>

Тем не менее, вы должны убедиться, что охват старой версии достаточно высок, иначе новые версии могут не быть перенаправлены на конкретную версию, которая вам нужна, и местоположение, использующее эту новую ссылку, не будет работать должным образом, поскольку старая ссылка уже находится в каталоге bin.

Для этой ошибки (и аналогичных) стоит пройти через NuGet Consolidate (Решение> Управление пакетами NuGet ...), чтобы убедиться, что одни и те же версии компонентов, на которые есть ссылки, согласованы в каждой библиотеке классов, на которую есть ссылка в решении, поскольку даже немного более старая версия может иметь зависимости на других старых компонентах. Его просто использовать вместе с обновлениями, и он может избавить вас от многих проблем.

Это решило эту проблему для меня, и я бы сказал, что с ней необходимо ознакомиться, если вы создаете вспомогательные библиотеки, которые также ссылаются на MVC или другие веб-компоненты NuGet.