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

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

Не удалось загрузить файл или сборку "System.Net.Http, Version = 2.0.0.0, Culture = neutral, 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

Я что-то пропустил?

UPDATE:

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

Ответ 1

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

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

Ответ 2

У меня была такая же ошибка при развертывании ранее конвертированного (от .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>

Теперь работает как прелесть.

Ответ 3

Моя работа с:

Обратите внимание на перенаправление от 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>

Ответ 4

В папке "Справочник проектов" должна быть ссылка на эту DLL, а версия должна быть 2.0.0.0. Убедитесь, что для этого параметра выбрано Копировать Local = true. И затем убедитесь, что он находит свой путь к папке bin вашего сервера.

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

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

Ответ 5

В моем случае я исправил его гораздо проще, просто дайте 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" />

Ответ 6

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

Изменить версию Microsoft.Net.Http в пакетах .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

Ответ 7

В файле config я удалил зависимую сборку:

<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>

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

Ответ 8

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

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

Исправлено, используя следующие шаги:

Загрузите автономный установщик .NET Framework 4.5 из ЗДЕСЬ
Отпустите установщик на машине развертывания

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

Ответ 9

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

Наконец, мы определили проблему.

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

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

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

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

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

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

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

Ответ 10

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

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

Ответ 11

Закройте проект, откройте его снова. Затем, Clean Solution + Build. Работает для меня

Ответ 12

Для версии 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>

Ответ 13

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

Ответ 14

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

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

или

B) Отсутствие доступа к папке для пользователя идентификатора пула приложений.

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

Ответ 15

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

"Не удалось загрузить файл или сборку GemBox.Spreadsheet, Версия = 39.3.30.1095, Культура = нейтральная, PublicKeyToken = b1b72c69714d4847 'или одна из его зависимостей. установленное определение манифеста сборки не соответствует сборке Справка. (Исключение из HRESULT: 0x80131040)"

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

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

Ответ 16

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

<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.

Ответ 17

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

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