System.Net.Http dll version problems

Last few weeks we had problems with referencing the correct System.Net.Http version. This is probably because some components use internally higher versions (.NET Core with System.Net.Http 4.2.0.0) compared to the versions that are available in NuGet.

Frequently we got errors like:
Could not load file or assembly 'System.Net.Http, Version=4.1.1.2, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

What is the solution.... That is a great questions. But we do not have the satisfying answer yet. What we currently do is the following.
- Use in all projects the same System.Net.Http version, currently we use v4.3.3 from nugget
- Compile the code and check in the resulting Bin folder what the resulting System.Net.Http version is
- Use this version as BindingRedirect in the app.config / web.config like

<dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.1.1.2" />
</dependentAssembly>

Replace 4.1.1.2 to the version of your current Dll. As you see here in the example above we also redirect the binding of newer versions to older versions.

The version of the DLL however is not the version for the BindingRedirect and is also different than the version used in NuGet..... pfffff. Here a mapping table for you to find the correct version

Version System.Net.Http.DLL Version NuGet Version BindingRedirect
4.6.25908.2
4.6.25705.1
4.3.3
4.3.3
4.2.0.0
4.1.1.2
4.6.24705.14.3.04.1.1.0
4.6.25514.44.2.0.04.2.0.0

An other Exception that we sometime get is a BadImageFormatException like:
Exception is: BadImageFormatException - Could not load file or assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Reference

This occurs when we build the application in x64 but there is a System.Net.Http.DLL used from x86. We normally fix this by copying the correct version of the DLL in the deployment.


Hope this helps, when I get more knowledge about this subject I will add more info and please post your solutions as comments!!!





Comments

David Frankland said…
I had this problem today. I had to downgrade a solution from .net 4.6.1 to 4.5.2 and I was getting the same error. The solution built OK, but failed at run-time.

I removed all references to System.Net.Http, then, like you, added version 4.3.3 using NuGet.

What I did to get it to work was delete the 4 line "dependentAssembly" section from each of the .config files. I didn't need to bother with version numbers, just threw the lines away.
Ana Del Campo said…
Thank you for your post, I ran into this problem, and after hours of trying, the only thing that resolve the issue was to manually copy System.Net.Http.Dll to the project's bin directory.
Ana Del Campo said…
Thank you for your post, I ran into this problem, and after hours of trying, the only thing that resolve the issue was to manually copy System.Net.Http.Dll to the project's bin directory.
Anonymous said…
Thank you, the solution is work. Recently I had this error. Probably visual stduio's bug
Unknown said…
Learned a lot of new things from your post!Good creation, It's amazing blog


.Net Online Training

Tristan Hyams said…
This comment has been removed by the author.
Tristan Hyams said…
Just noticed while installing NuGet 4.3.3, Visual Studio 2017, in its infinite wisdom, has been sneaking the old Add Reference DLL thats in the host GAC.

It's version 4.2.0.0 in 4.7.2.

Install the NuGet, remove that stupid DLL reference, and remove the bindings and it will work again.
Mark said…
@Tristan Hyams what do you mean by "remove that stupid DLL reference"?

We've ran in to this issue a few times now on different projects and resolve it with rebinding back to 4.1.1.2 instead of 4.2.0.0 that .NET is providing as the reference DLL for .NET Framework 4.7.2. We don't have any DLL reference to 4.2.0.0, we can see in the build it is the build deciding to service up the reference DLL even though the reference in our project is to 4.1.1.2.

Are you suggesting to change our project references to use 4.2.0.0 and remove the bindings? I don't think that would work for us as we have other NuGet packages that still want the 4.1.1.2 version.

Popular posts from this blog

SharePoint Survey Back Button

How to set up AD FS for a development machine