Found conflicts between System.Net.Http

Question

I have several projects in my VS solution. Whenever I add "System.Net.Http" NuGet package to one it shows as version 4.2.0.0. Then I do the same and add same NuGet Package, however, the other says version. 4.1.1.2

Then I get a warning:

Found conflicts between System.Net.Http

EDIT1:

Gathering dependency information took 1.7 sec
Attempting to resolve dependencies for package 'System.Net.Http.4.3.3' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'System.Net.Http.4.3.3'
Resolved actions to install package 'System.Net.Http.4.3.3'
Retrieving package 'System.Net.Http 4.3.3' from 'nuget.org'.
Adding package 'System.Net.Http.4.3.3' to folder 'C:\...Service\packages'
Added package 'System.Net.Http.4.3.3' to folder 'C:\...Service\packages'
Added package 'System.Net.Http.4.3.3' to 'packages.config'
Successfully installed 'System.Net.Http 4.3.3' to ....Service
Executing nuget actions took 2.05 sec
Time Elapsed: 00:00:03.8937113

Please notice correct version installed, However => Props => Version says 4.1.1.2

Answer 1

Edit: This happens only when using .NET Framework. In .NET Core/Standard land, the latest System.Net.Http assembly version seems to be always 4.1.2.0 - there is no 4.2.0.0 version available.

The issue regarding System.Net.Http is way, way more complicated then the answers here seem to imply...

1. Yes, there is a System.Net.Http NuGet package, but no, it will not install the latest version of the same assembly (it contains version 4.1.1.2 of the System.Net.Http assembly, not 4.2.0.0).
   Update 19Mar2022: the latest NuGet package Version 4.3.4 has assembly version 4.1.1.3, assembly version 4.2.0.0 still is not directly installed.
2. Latest Microsoft Visual Studio (or Microsoft Visual Studio Build Tools) provides version 4.2.0.0, but that does not mean your .csproj will always use it...
3. For some reason (which I was not able to understand yet), the only guaranteed way of using 4.2.0.0 is by referencing certain NuGet packages that uses it, such us System.Buffers (version 4.5.0 worked for me).

TL;DR:

Add System.Buffers 4.5.0+ NuGet reference to your project, if you want to make sure it is using System.Net.Http 4.2.0.0 assembly.

References:

• https://github.com/dotnet/corefx/issues/17522
• https://github.com/dotnet/corefx/issues/25773
• (https://github.com/dotnet/corefx/issues/22781 -broken link)

Answer 2

After going through all the solutions presented here and the references cited in this answer, I finally resolved this completely. This is what I believe anyone who experiences this issue should do:

1. Update all NuGet packages to latest.
2. Migrate NuGet from packages.config to PackageReference as per the instructions here. Basically, for each project in your solution, In Solution Explorer, right-click on the References node or the packages.config file and select Migrate packages.config to PackageReference.... ASP.NET website projects must remain using packages.config.
3. Remove any references to System.Net.Http that are not managed by NuGet (for projects using PackageReference, you should see the NuGet symbol next to the reference in Solution Explorer). Replace the removed System.Net.Http references with the corresponding NuGet package if you're certain your project requires System.Net.Http (try building without it first). For projects using packages.config, take extra care to ensure that references to System.Net.Http are required and that they are also using NuGet. It may help to remove and re-add System.Net.Http via NuGet anyway (for all projects referencing it), even if already referenced using NuGet. I found that step 2 can cause some disjoint somewhere.
4. Upgrade to .NET Framework 4.7.2 for the reasons described here. This is part of VS 2019. Otherwise, download it from here or use the Visual Studio Installer for VS 2017.
5. Remove all the assembly bindings from all app.config and Web.config files then build your solution. app.config bindings are not required anymore. Web.config bindings will be re-added in the next step, but removing them first ensures you don't have any outdated versions in your bindings.
6. You may now get some other conflicts at this stage. For your ASP.NET website projects, add the binding redirects to your Web.config that are given to you in the warnings. For other .NET Framework applications, for the references that you are getting warnings for, add the corresponding NuGet packages in the projects where you are getting the warnings, even if the project compiles without the reference being added. This forces the project to use the NuGet version and not the local .NET Framework version that might be getting referenced by another package. This is due to cross-over between .NET Framework and .NET Standard as alluded to by rsenna's aforementioned answer. After building, you may need to repeat this step for further references.

If you later find that you get run-time exceptions (even during unit testing) due to manifest mismatches after adding a reference somewhere, remove all the binding redirects from the website project concerned, then re-add the suggested ones given in the warning as per step 6.

I spent a lot of time trying to resolve this issue methodically, so I believe the above steps would fully resolve most people's issues, although some lateral thinking might be required for unusual cases. Let me know if this works (or doesn't work) for you.

Answer 3

This tends to happen when you have a reference to the framework System.Net.Http, but one of your package references requires the NuGet package System.Net.Http.

See if you have a reference to that assembly, remove it and install the NuGet package instead

Answer 4

There is a new solution to this that works as of the 9th of October 2018.

1. You will need to update all your references to System.Net.Http to the latest version 4.3.4.
2. You should install the package into your .Net framework solution that is causing the conflict, even if it does not explicitly require the package.

3. If your project has the new project structure, edit it and make sure it includes the following package reference:

   <PackageReference Include="System.Net.Http" Version="4.3.4" />
   

4. Search your solution and delete any existing binding redirects for System.Net.Http they will look as follows

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

5. Rebuild, the warning should now be gone and your code should build and run fine

Answer 5

You can force the version you're installing, so you can have both projects aligned or find a message in the output window, which would be telling you what's wrong or what your dependencies are. Since the official link lists no 4.2 release, I would do this (solution-wide)

Install-Package System.Net.Http -Version 4.1.1

Or for both projects

Get-Project ProjectName | Install-Package System.Net.Http -Version 4.1.1

Or, even better (using the last version)

Install-Package System.Net.Http -Version 4.3.3

EDIT

Apparently you are not the first to experience this. How about the answer here? Basically you can align this section of both projects config file:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

You might have to adapt the token value. Just in case, could you paste the config file for both projects=

Answer 6

The 6 steps that Neo posted above helped me solve my ASP.NET package problems! Thank you Neo! I was dealing with this for over a week.

I just want to share my personal notes from my experience of implementing Neo's post above.

I had an ASP.NET Web API project that targeted .Net Framework 4.6.1

Here is what I did:

• Upgrade to .Net Framework 4.7.2
• Update all NuGet packages to the latest.
• (optionally, could also do "update-package -reinstall" to make sure all packages are associated with 4.7.2)
• Consolidate packages
• I did not migrate from packages.config to PackageRefence, because you can't in ASP.NET
• Removed references from System.Net.Http and others that required it, and added them as NuGet packages.
• Removed all assembly bindings from web.config and app.config (in .Core, .Tests, .IntegrationTests libraries)
• Added binding redirects for our in-house NuGet packages that had version numbers that ended with text (n.n.n.n-beta), but removed text and had numbers only (n.n.n.n)
• Added this to all .csproj files:
  • MSBuild and <AutoUnifyAssemblyReferences />
  • https://github.com/Azure/azure-webjobs-sdk/issues/1598

<PropertyGroup>
  <AutoUnifyAssemblyReferences>true</AutoUnifyAssemblyReferences>
</PropertyGroup>

• Make sure the packages in all packages.config files have the same versions in all projects in the solution
  • Make sure the versions are the same in the web.config
  • Make sure the versions are the same in the .csproj file, if applicable
• Use Microsoft.Net.Compilers 3.1.1 (update all .csproj files in solution, including .Tests and .IntegrationTests)
• For Data Protection API (DPAPI) that use Redis:
  • Install Microsoft.AspNetCore.DataProtection.StackExchangeRedis 2.2.5
  • StackExchange.Redis 2.0.601
  • Update System.Numerics.Vectors to 4.4.0 (note: 4.5.0 has a bug in it that prevents server connection)

Answer 7

I've had this problem twice now whilst working with Azure Worker roles. Any called to system.net.http simple causes the code to hang, but there is no feedback at all from Azure so it takes hours or days of commenting out code to find the cause let alone a solution.

A simple trick fixed it for me. This isn't my solution, I came across it about 6 months ago, but when the problem happened to me again today, I thought it worth posting.

1. Delete any references to System.Net.Http from your project
2. Go to "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib"
3. Create a new directory, for example "temphide"
4. Move all System.Net.* DLL's into this directory
5. Now when you deploy, your project will use the Nuget version, no more conflicts

Answer 8

I tried out various solutions (removing the dependentAssembly OR specifying the binding redirect as well). None of them worked.

However, the only solution which worked for me was to explicitly set Specific Version for System.Net.Http (or whatever DLL giving you version issues) to False from Visual Studio.

Answer 9

After spending many days on various projects, trying to fix this recurrent hell: here is a reliable fix that does not break after some time. Tested with 4.6.1 and 4.7.2.

Fix process

Fix your developer machine:

• Remove all references to the nuget package "System.Net.Http"
• Open the "%ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2" directory (adapt to your specific version).
  • locations may differ on your machine, see this answer
• In this directory: locate the special file System.Net.Http.dll
• In this directory: rename "System.Net.Http.dll" to "System.Net.Http.dll.backup"

Do that on all developer machines. This will not break your machine.

In your projects: just add basic "Assembly Reference" for "System.Net.Http".

In your runnable projects (Web/CLI): you might need to set the project reference as "Copy local" to have the correct dll copied when publishing somewhere else.

    <Reference Include="System.Net.Http">
      <Private>true</Private>
    </Reference>

You may add this assembly redirect (app.config/web.config) in some cases:

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

Why does this work?

It seems the build process is able to see this special file exists. The build will then generate problematic references. This will lead to the exceptions you know well.

Making the file invisible (due to the file extension change) will prevent the build process from doing this crazy stuff.

What is this specific file? Is it special?

This file is fake news. Decompile it, you will see it is empty!
They just put it there to turn us crazy [citation needed].

Locations may vary:

• when SDK installed:
  • "%ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2"
• without SDK:
  • "%ProgramFiles(x86)%\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib"

Wait, you can't delete a system file!

That's what I (and others) concluded for some years. This problem continues to come back many times a year. This solution is not as bad as you think, since the problematic file is a FAKE assembly.

Learn more

This dotnet issue on github contains a huge volume of information about the problem. This answer explains the transitive dependency phenomenon that is part of the global problem. This answer suggests deleting the bad dlls.

Oops, it seems I am partially duplicating Steven Elliott's answer. Mine is more detailed though.

Answer 10

Just remove the system.net.http reference from different projects/Class libraries and add the reference again.

Answer 11

I am working with .NET 4.6.2 and found the same problem. I have two projects a web site and a test project. I review the following:

• Both project has installed the NuGet package for System.Net.Http

• The references in both program are equal and both point to the same
  package

The Problem. The Web.Config and the App.Config from the project point to different System.NET.Http.

I substitute the code in both config to get:

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

in both of them. Then the conflict disappear.