Не вдалося завантажити файл або збірку 'System.Net.Http, Версія = 2.0.0.0 у веб-API MVC4

У мене трохи дивна проблема.
Я розробив додаток з 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 і чому він буде працювати локально, але не на сервері.

Переглядаючи залежності від самородків:

Основні бібліотеки API ASP.NET WEb (Beta) залежать від 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, якщо навіть навіть сам додаток не знаходжу.

У мене була та ж проблема з розгортанням мого додатка в appharbor. Проблема, яку він ще не підтримує .NET 4.5. Що я зробив.

1. Переключив мій проект на профіль .NET 4.0.
2. Видалений пакет NuGet Web API.
3. Знову встановлено пакет NuGet веб-API (бета-версія).
4. Перевірено, що файл .csproj містить ВСІ збірки, на які посилаються, тому він завжди буде брати його з папки Bin, замість GAC.

У мене виникла та сама помилка під час розгортання раніше перетвореного (з .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>

Зараз працює як шарм.

Шахта працювала з:

Зверніть увагу на перенаправлення з 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. Переконайтеся, що для цього встановлено значення Копіювати локально = істина. А потім переконайтеся, що він знаходить свій шлях до папки кошика вашого серверного додатка.

Це одна з бібліотек, якою зараз керує 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 Package Manager (оскільки інші пакети, здавалося, залежали від нього). Однак ці пакети не залежать від цієї конкретної версії. Ось що я зробив, щоб позбутися цього (замість цього ви також можете використовувати консоль NuGet (використовуючи параметр –force):

• Змініть версію Microsoft.Net.Http у пакетах.config з 2.1.10.0 на 2.0.0.0
• Видаліть BCL Portability Pack у NuGet Package Manager
• Позбудьтесь вручну залежних бібліотек (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 між моєю машиною DEV та сервером розгортання, вони не збігалися.

Виправлено за допомогою наведених нижче кроків:

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 була розміщена: .. \ пакети \ 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") та переінсталював їх. Просто зробив кілька клацань.

Закрийте проект, відкрийте його знову. Потім Clean Solution + Build. Працює для мене

Для версії 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, які все ще висять, і які слід було видалити

або

Б) Відсутність доступу для читання до папки для користувача ідентифікатора пулу програм.

Іншими словами, для нас це було вирішено шляхом виправлення дозволів на папки для сайту та знищення папки bin та перерозподілу.

У мене була та ж проблема з Gembox.spreadsheet.dll версії 31.

"Не вдалося завантажити файл або збірку 'GemBox.Spreadsheet, Версія = 39.3.30.1095, Culture = neutral, 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 Consolidate (Рішення> Керування пакетами NuGet ...), щоб переконатися, що однакові версії компонентів, на які посилаються, узгоджуються в кожній бібліотеці класів, на яку посилається рішення, оскільки навіть трохи старша версія може мати залежності на інших старих компонентах. Це просто для використання разом із оновленнями та може заощадити багато болю.

Це вирішило цю проблему для мене, і я б сказав, що потрібно ознайомитись, якщо ви створюєте допоміжні бібліотеки, які також посилаються на MVC або інші веб-компоненти NuGet.