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

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

в интернете.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. Убедитесь, что установлено значение копировать 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" />

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

• изменить версию Microsoft.Сеть.Http в пакетах.config с 2.1.10.0 к 2.0.0.0
• удалить пакет переносимости BCL в Диспетчере пакетов NuGet
• вручную избавиться от зависимых библиотек (System.Сеть.Http.* которые имеют версию 2.1.10.0)
• добавить ссылку на систему.Сеть.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. запуск установщика при развертывании машина!--1-->

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

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

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

при создании нового веб-API MVC 4 и выборе framework 4.0 при создании проекта мы нашли правильную версию пакета NuGet для DLL в: ..\packages\Microsoft.Net.Http.2.0.20710.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 все еще висят вокруг, которые должны были быть удалены

или

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

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

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

" не удалось загрузить файл или сборку GemBox'.Электронная таблица, Версия=39.3.30.1095, культура=нейтральная, 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 (решение > Управление пакетами NuGet...) обеспечить согласованность версий компонентов, на которые ссылается решение, в каждой библиотеке классов, поскольку даже более старая версия может иметь зависимости от других более старых компонентов. Он прост в использовании в сочетании с обновлениями и может сэкономить много боли.

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