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

92

У меня немного странная проблема.
Я разработал приложение с 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, если даже не найдет само приложение.

Реми
источник
Вы использовали функцию «Добавить развертываемые зависимости» для этого проекта?
ChristiaanV
Нет, не пробовал. Но я настроил все по-новому, и теперь все работает .... Не очень хорошо, но ...
Реми
У меня эта проблема возникает каждый раз, когда я перезапускаю свою машину и перезапускаю визуальную студию. Каким-то образом это исчезло, если я очистил, а затем восстановил решение.
frostshoxx 04

Ответы:

30

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

  1. Переключил мой проект на профиль .NET 4.0.
  2. Неустановленный пакет NuGet веб-API.
  3. Снова установлен пакет NuGet для веб-API (бета).
  4. Проверено, что файл .csproj содержит ВСЕ указанные сборки, поэтому он всегда будет брать его из папки Bin, а не из GAC.
Александр Белецкий
источник
1
Каким-то образом мой проект заработал, но я не знаю почему ... Ваш подход кажется осуществимым.
Реми
alexanderb - как перейти на профиль .NET 4.0. В Visual Studio? Где находится папка bin? Является ли файл .csproj файлом web.config? Thx
WhoAmI 05
114

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

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

Кшиштоф
источник
4
Должны ли сборки по-прежнему быть настроены на локальное копирование с этим изменением?
Расмус Кристенсен
3
Проблема для меня заключалась в том, что один из моих пакетов NuGet Web Api зависел от System.Net.Http 2.0.0.0, но моя ссылка была 2.1.10.0, которая выводилась в мою папку bin.
JustinMichaels
2
Это правильно (как сказал Джастин Майклс). Зависимость относится к 2.0.0.0, но ваша ссылка на сборку - на 2.1.xx Все, что вам нужно исправить, - это перенаправление привязки.
Tod Thomson
2
Этот ответ должен быть отмечен как правильный. Я думаю, именно поэтому все остальные пользователи продвигают эту опцию. Спасибо, Кшиштоф!
Blaise
3
Проблема, вероятно, не в прямой ссылке на System.Net.Http, а в косвенной ссылке, которая используется в одной из других библиотек, на которые вы ссылаетесь. Вот почему установка локального копирования обычно не решает эту проблему.
Пол Кейстер
10

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

Обратите внимание на перенаправление с 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>
Клайв
источник
Я сделал что-то подобное, но обновил newVersion до 4.0.0.0 и оставил oldVersion как 0.0.0.0-2.0.0.0
Veritoanimus
2

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

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

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

GeekyMonkey
источник
1
Собственно вот что меня смущает. Я использую nuget и у меня есть эта папка. Но если я посмотрю на System.Net.Http, у него будет версия 1.0.0.0
Реми
1
Именно так я это исправил! Так как все работало локально. Я просто щелкнул правой кнопкой мыши ссылку и в свойствах установил Copy localзначение true, что разрешает его! проще / лучше, чем возиться с файлами web.config. Просто добавьте dll в папку bin.
JP Hellemons
2

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

В моем случае я непреднамеренно добавил зависимость к 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
Dunken
источник
1

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

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

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

СтефаноМ5
источник
Чтобы правильно отображать теги XML - отформатируйте текст как код. Для этого просто добавляйте четыре пробела перед каждой строкой.
Artemix
Tnx Artemix, это мой первый комментарий;)
StefanoM5
1

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

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

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

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

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

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

Судханшу Мишра
источник
1

Мы используем 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.

Эрик Рейсс
источник
1

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

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

Руди Скоггинс
источник
0

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

Lücks
источник
0

Для версии 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>
Усама
источник
0

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

Хавьер Гонсалес
источник
0

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

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

или

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

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

Крис Москини
источник
0

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

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

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

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

Рачана
источник
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>

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

Микаэль
источник
0

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

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

mhapps
источник