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

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

в интернете.конфигурации 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>

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

мой работал с:

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

в папке ссылок вашего проекта должна быть ссылка на эту 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" />

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

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

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

1. скачал автономный установщик .NET Framework 4.5 из здесь

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

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

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

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

Я пошел в менеджер 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.