it-swarm.com.ru

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

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

91
Remy

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

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

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

В разделе web.configruntimeя нашел

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

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

111
Krzysztof

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

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

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

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

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

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

2
GeekyMonkey

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

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

1
Rudy Scoggins

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

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

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

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

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

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

1
Sudhanshu Mishra

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

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

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

Мы используем 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 все еще работает find.

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

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

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

1
Eric Reiss

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

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

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

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

0
Rachana

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

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

0
mhapps

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

0
Javier Gonzalez

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

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

или же

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

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

0
Chris Moschini

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

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

<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
Micaël

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

0
Lücks