Не удалось загрузить файл или сборку 'System.Net.Http, версия = 2.0.0.0 в MVC4 Web API - PullRequest
91 голосов
/ 24 февраля 2012

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

Не удалось загрузить файл или сборку 'System.Net.Http, версия = 2.0.0.0, культура = нейтральная, 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, если даже не найду само приложение.

Ответы [ 17 ]

113 голосов
/ 20 апреля 2012

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

В web.config runtime секцию, которую я нашел

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

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

30 голосов
/ 28 марта 2012

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

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

Шахта работала с:

Обратите внимание на перенаправление от 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>
2 голосов
/ 23 сентября 2014

В моем случае я исправил это гораздо проще, просто укажите 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" />
2 голосов
/ 28 февраля 2012

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

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

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

1 голос
/ 26 июля 2013

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

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

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

1 голос
/ 20 июня 2013

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

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

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

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

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

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

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

1 голос
/ 03 августа 2015

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

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

1 голос
/ 15 мая 2014

Мы используем 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 для этого проекта указан путь к этой системеФайл .net.http.dll: .. \ packages \ Microsoft.Net.Http.2.0.30506.0 \ lib \ net40 \ System.Net.Http.dll

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

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

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

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

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

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