Could not load file or assembly 'System.Net.Http, Version=2.0.0.0 in MVC4 Web API

Question

I have a bit of a weird problem.
I developed an app with MVC 4 and the new Web API and it works fine locally. I installed MVC4 on the server and deployed the app. Now I get the following error:

Could not load file or assembly 'System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in

Funny enough, the version of System.Net.Http that I locally have either in my package folder or in the ASP.NET MVC 4\Assemblies folder is 1.0.0.0. I actually removed the reference to System.Net.Http from my project, but I still get the same message. I'm a bit confused about where it gets the 2.0.0.0 reference from and why it would work locally but not on the server.

Looking at the nuget dependencies:

ASP.NET WEb API Core Libraries (Beta) depends on System.Net.Http.Formatting.
And System.Net.Http.Formatting depends on System.Net.Http.
I guess that is where this comes from. But I do have Version 2.0.20126.16343 of this package installed, it's just that the dll inside has version 1.0.0.0

Am I missing something?

UPDATE:

This is a sub-application of another ASP.NET app, but the other one is still based on WebForms. So, something is getting messed up. But if I do a clean under the assembly section in the web.config if does not even find the app itself anymore.

Did you use the "Add deployable dependencies" feature for this project? — ChristiaanV, Feb 27 '12 at 11:19
No, did not try that. But I've set everything up fresh and now it works.... Not really satisfying, but... — Remy, Feb 27 '12 at 16:45
I have this issue every time I restarted my machine and relaunch visual studio as well. Somehow it went away if I do clean and then rebuild the solution. — frostshoxx, Jan 04 '16 at 14:11

score 116 · Answer 1 · edited Sep 30 '13 at 17:59

116

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.

edited Sep 30 '13 at 17:59

shanabus

12,601
6
47
75

answered Apr 20 '12 at 16:17

Krzysztof

1,296
2
7
8

4

Should the assemblies still be set to copy local with this change? – Rasmus Christensen May 17 '12 at 08:06
3

The problem for me was that one of my Web Api NuGet packages held a dependency on System.Net.Http 2.0.0.0 but my reference that I had was 2.1.10.0 that was being outputted to my bin folder. – JustinMichaels Jun 04 '13 at 17:10
2

This is correct (as Justin Michaels said). Dependency refers to 2.0.0.0 but your assembly reference is to 2.1.x.x. All you need to fix this is the binding redirect. – Tod Thomson Jul 24 '13 at 00:05
2

This one should be marked as the correct answer. I guess that is why all other users are pushing up this option. Thank you, Krzysztof! – Blaise Aug 19 '13 at 17:47
3

The problem is probably not the direct reference to System.Net.Http, but an indirect reference that is used in one of the other libraries you're referencing. That's why setting copy local generally won't fix this problem. – Paul Keister Sep 12 '13 at 18:39
1

This also happens when NuGet updates the library. You then have to manually change the binding redirects. – Uwe Keim Sep 30 '13 at 14:52
1

I did the opposite for my project, go figure. – Mark Schultheiss Dec 30 '13 at 19:46
Fixed my issue. There were a *ton* of binding redirects in my web config – K0D4 Jul 25 '14 at 23:25
1

Simply *comment out* the entire `bindingRedirect` (also removing it's parent `dependentAssembly` element) has been working great for me. NuGet does like to put it back, as @UweKeim mentioned – bkwdesign Jul 13 '17 at 03:10

score 31 · Accepted Answer · answered Mar 28 '12 at 07:25

31

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

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

answered Mar 28 '12 at 07:25

Alexander Beletsky

18,109
9
57
84

1

Somehow my project started working, but I haven no clue why... Your approach seems feasible. – Remy Mar 30 '12 at 09:29
alexanderb - how do i change to .NET 4.0 profile. In Visual Studio? Where is the bin folder located? Is the .csproj file the web.config file? Thx – WhoAmI Mar 05 '14 at 08:11

score 10 · Answer 3 · answered Aug 05 '12 at 20:58

10

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>

answered Aug 05 '12 at 20:58

Clive

1,068
2
11
19

I did something likethis, but I updated newVersion to 4.0.0.0 and left oldVersion as 0.0.0.0-2.0.0.0 – Veritoanimus Apr 14 '15 at 18:58

knocte · Answer 4 · 2014-10-07T06:25:36.123

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

score 2 · Answer 5 · answered Feb 28 '12 at 01:59

2

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.

answered Feb 28 '12 at 01:59

GeekyMonkey

10,933
5
30
36

1

Actually, that is what confuses me. I use nuget and I have this folder. But if I look at System.Net.Http it has Version 1.0.0.0 – Remy Feb 28 '12 at 08:59
1

This is exactly how I fixed it! Since it all worked locally. I just right clicked the reference and in properties, I have set `Copy local` to **true** which resolves it! easier/better then messing around in web.config files. Just add the dll to your bin folder. – JP Hellemons Jan 24 '13 at 11:48

score 1 · Answer 6 · answered Jun 20 '13 at 07:48

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

score 1 · Answer 7 · edited Jul 26 '13 at 10:13

1

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.

edited Jul 26 '13 at 10:13

Artemix

1,899
2
21
32

answered Jul 26 '13 at 09:47

StefanoM5

1,237
1
22
32

To show XML tags properly - format your text as a code. For this just add four spaces before each line. – Artemix Jul 26 '13 at 10:11
Tnx Artemix, this is my first comment ;) – StefanoM5 Aug 07 '13 at 07:30

score 1 · Answer 8 · answered Oct 08 '13 at 13:02

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:

Downloaded .NET Framework 4.5 Standalone installer from HERE
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!!

score 1 · Answer 9 · answered May 15 '14 at 16:12

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.

score 1 · Answer 10 · answered Aug 03 '15 at 14:12

1

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.

answered Aug 03 '15 at 14:12

Rudy Scoggins

371
2
7

score 0 · Answer 11 · answered Aug 22 '13 at 01:22

0

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

answered Aug 22 '13 at 01:22

Lücks

3,294
2
35
52

score 0 · Answer 12 · answered Oct 01 '13 at 13:59

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>

score 0 · Answer 13 · answered Dec 12 '13 at 19:18

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!

score 0 · Answer 14 · answered Jul 23 '14 at 21:33

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.

score 0 · Answer 15 · edited Jan 28 '16 at 20:05

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.

score 0 · Answer 16 · answered Feb 08 '16 at 11:23

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.

score 0 · Answer 17 · answered Feb 08 '17 at 11:48

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.

Could not load file or assembly 'System.Net.Http, Version=2.0.0.0 in MVC4 Web API

17 Answers17

Linked

Related