无法在 MVC4 Web API 中加载文件或程序集“ System.Net. Http，Version = 2.0.0.0”

我有个奇怪的问题。
我用 MVC 4和新的 Web API 开发了一个应用程序，它在本地工作得很好。 我在服务器上安装了 MVC4并部署了应用程序:

无法加载文件或程序集“系统”。网。Http，Version = 2.0.0.0，Culture = 材质，PublicKeyToken = 31bf3856ad364e35’或其依赖项之一。找到的程序集的清单定义与程序集引用不匹配。(来自 HRESULT T: 0x80131040的异常)

描述: 在当前 Web 请求的执行过程中发生了一个未处理的异常。请查看堆栈跟踪，以获得有关错误的更多信息以及错误的起源位置

有趣的是，系统的版本。网。我本地的包文件夹或 ASP.NET MVC 4 Assembly 文件夹中的 Http 是1.0.0.0。 我实际上删除了对 System 的引用。网。从我的项目 Http，但我仍然得到相同的消息。我对它从哪里获得2.0.0.0引用以及为什么它能在本地工作而不能在服务器上工作感到有点困惑。

看看对 nuget 的依赖:

NET WEb API 核心库(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 的组装部分下面做了一个清理，那么就会发现这个应用程序本身已经不存在了。

173892 次浏览
小开

In your project's References folder there should be a reference to this dll, and the version should be 2.0.0.0. Make sure this is set to Copy Local = true. And then make sure it finds its way to your server app's bin folder.

This is one of the libraries that is now managed by nuget. So open Nuget and make sure everything is up to date. And in your projects packages directory the file should be here: \packages\System.Net.Http.2.0.20126.16343\lib\net40

You could also try creating a new MVC4 app and see if the file shows up for that one.

小开
最佳答案

I had the same problem with deployment my app to appharbor. The problem it does not support .NET 4.5 yet. What I did.

  1. Switched my project to .NET 4.0 profile.
  2. Uninstalled Web API NuGet package.
  3. Installed Web API (Beta) NuGet package again.
  4. Verified that .csproj file contains for ALL referenced assemblies, so it will always take it from Bin folder, instead of GAC.
小开

I had the same error while deploying previously converted (from .NET 4.5 to 4.0) web app on IIS 6.0.

In the web.config runtime section I've found

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

which I've changed to

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

Now works like charm.

小开

Mine worked with:

Note the redirect of 1-4 to 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>
小开

In my case I unintentionally added a dependency to System.Net.Http version 2.1.10.0 through NuGet. I couldn’t get rid of it in the NuGet Package Manager (because other packages seemed to be dependent on it). However those packages aren’t dependent on this particular version. Here's what I did in order to get rid of it (you can also use the NuGet console instead (using the –force parameter):

  • Change version of Microsoft.Net.Http in packages.config from 2.1.10.0 to 2.0.0.0
  • Uninstall BCL Portability Pack in NuGet Package Manager
  • Manually get rid of dependent libraries (System.Net.Http.* which have version 2.1.10.0)
  • Add a reference to System.Net.Http 2.0.0.0
小开

In file config I deleted dependent Assembly: 

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

Now it works fine.

小开

Close the project, Open it again. Then, Clean Solution + Build. Works for me

小开

For version 2.2.15.0, I did this:

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

I was facing this issue on a test server (Windows 2008 R2) which was supposedly "ready" for deployment ;)

The hint was that when I checked the versions of System.net between my DEV machine and deployment server, they did not match.

Fixed using the steps below:

  1. Downloaded .NET Framework 4.5 Standalone installer from HERE

  2. Ran the installer on the deployment machine

Post installation of the framework, server wanted a reboot, so did that and volla! We are good to go!!

小开

I had this exact same issue! I took a look at my Warnings tab in VS and noticed that one of my nuget packages was INDIRECTLY referencing .NETFramework Version 4.5.0.0. I had to uninstall this package and then reinstall the 4.0 version but be sure to specify the package versions that support 4.0(it'll default back to 4.5 i believe if you don't specify when installing the package). Hope this helps!

小开

We are using VS 2013, created a new MVC 4 Web API and had a problem with the system.net.http.dll not being the correct version when built on our TeamCity server but it builds fine on our local developer machines that have VS 2013 installed.

We finally determined the problem.

When creating a new MVC 4 Web API and choosing the framework 4.0 on project creation we found the the correct NuGet package version for DLL was being put in: ..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll

However the .csproj file for this project said the path for this system.net.http.dll file is: ..\packages\Microsoft.Net.Http.2.0.30506.0\lib\net40\System.Net.Http.dll

So when the build is attempted is fails on this path difference but is finding the correct framework version of the file elsewhere on the developer machine but not on our TeamCity build server.

So far this is the only difference we found. Changing the path in the .csproj file and building on local Dev machine with VS2013 still works find.

Checking that into version control and having our TeamCity build server (without VS 2013 installed locally) now finds the correct version of the .dll in its NuGet package folder for the solution and builds successfully rather than searching for another version of system.net.http.dll and finding a newer version which doesn't match the framework hence causing build failures.

Not sure if this helps.

Check your project file path for the DLL and make sure it matches your package folder path for the DLL.

小开

We had this happening on a server after deployment. It was caused either by:

A) Old files in the bin folder still hanging around that ought to have been deleted

or

B) Not having read access to the folder for the Application Pool Identity user.

In other words, for us this was resolved by fixing permissions on the folders for the site and wiping out the bin folder and redeploying.

小开

In my case I fixed it in a much easier way, just give a HintPath to the reference to the nuget package:

     <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" />
小开

Just simplifying the other answers for what worked for me.

I went to the NuGet manager, uninstalled the related packages (In my case, "Microsoft ASP.NET Web API 2.1 Client Libraries" and "Json.NET") and reinstalled them. Just took a few clicks.

小开

I had the same issue with Gembox.spreadsheet.dll version 31.

" Could not load file or assembly 'GemBox.Spreadsheet, Version=39.3.30.1095, Culture=neutral, PublicKeyToken=b1b72c69714d4847' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) "

I tried almost everything from these articles and none of them worked. It just got fixed with simple step.

I tried building individual projects that basically set up the correct version reference to the dll and the error was entirely gone from the solution.

小开

Go a similar issue and the directive mentionned in many comments worked fine

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

Although, you have to ensure the old version coverage is high enough otherwise newer versions may not be redirected to the specific version you need and location using that newer reference won't work properly since the older reference is already in the bin directory.

小开

For this error (and similar) it's worth going through NuGet Consolidate (Solution > Manage NuGet Packages...) to ensure the same referenced component versions are consistent in each class library referenced in the solution, since even a slightly older version may have dependencies on other older components. It's straightforward to use in conjunction with Updates and can save a lot of pain.

This solved this issue for me and I would say it's a must to get familiar with if you're creating helper libraries that also reference MVC or other web-based NuGet components.


提交答案