10

Using VS2017, I've created a ClassLibrary (.NET Framework 4.6.2) in an empty solution. Then I've installed System.Net.Http 4.3.2 package there and used HttpClient class in a Class1 constructor.

Then I've created a ConsoleApp (.NET Framework 4.6.2), referenced ClassLibrary and instantiated Class1 in the Main method.

Now running ConsoleApp causes runtime exception:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. at ClassLibrary1.Class1..ctor() at ConsoleApp1.Program.Main(String[] args) in [...]

In detailed build log I see this message:

2> There was a conflict between "System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".

2> "System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was chosen because it was primary and "System.Net.Http, Version=4.1.1.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" was not.

Let's suppose I can not remove reference to System.Net.Http from ConsoleApp, because I have this situation in a real project structure.

  • Playing with Specific Version parameter of System.Net.Http reference did not help.
  • Specifying <bindingRedirect oldVersion="0.0.0.0-4.1.1.1" newVersion="4.1.1.1" /> did not help

I've googled it and it is a popular problem, but I didn't find a clear explanation of what actually happens and how to fix such cases in general.

Could not load file or assembly System.Net.Http version 4.1.1.0

Could not load file or assembly 'System.Net.Http' or one of its dependencies

About conflicts:

What does .NET mean by 'primary' when choosing between conflict dll reference?

Found conflicts between different versions of the same dependent assembly that could not be resolved error

astef
  • 8,575
  • 4
  • 56
  • 95
  • Because, basically, MS screwed up: https://github.com/dotnet/corefx/issues/11100 – Gaute Løken Aug 28 '17 at 11:43
  • Really? Didn't get an idea what happened, can you explain in answer? – astef Aug 28 '17 at 11:49
  • 5
    They added some features to System.Net.Http for .net core. When targetting it (through .NET Standard) from a framework 4.6.1/4.6.2 app, there was a regression due to security requirement that was added, which broke things in framework apps. But they couldn't recover from it by adding a redirect to an older version, as that would potentially break apps using those new features. So it's left as an exercise for the developer to maintain redirects, which nuget will overwrite. Yep, it's a mess. :( – Gaute Løken Aug 28 '17 at 12:06
  • 1
    The positive is that if you change your redirect to target 4.0.0.0, chances are it will work. – Gaute Løken Aug 28 '17 at 12:07
  • http://wiki.c2.com?HoursOfFun – mortb Sep 05 '17 at 14:19
  • Does this answer your question? [Found conflicts between System.Net.Http](https://stackoverflow.com/questions/48866419/found-conflicts-between-system-net-http) – Michael Freidgeim Dec 20 '20 at 00:13

2 Answers2

2

I wonder why you are choosing to use the NuGet package instead of using the Reference Manager to load in the appropriate assembly. By default in a lot of project templates VS includes System.Net.Http. If it is the case that you used the NuGet package explorer to install the assembly, then one of the two options should help out:

  1. Remove the NuGet package and use the assigned version from the Reference Manager (look under Assemblies / Framework) though I am betting this is already selected.

  2. In the Reference Manager un-select the assigned version of System.Net.Http and use the one that you installed with NuGet.

Personally I think option 1 is better unless you absolutely need something specific found only in the NuGet latest version.

Kodaloid
  • 1,211
  • 11
  • 19
  • 1
    In a real project I forced to install the `System.Net.Http` nuget package to one of my projects due to indirect dependency (and this caused everything to fail in runtime, very nice). Migrating from reference to this package in all other projects is a bit pain, I want to avoid it – astef Jul 26 '17 at 17:32
  • There in lies your problem then, you have a conflict between the two, and the only way to fix the conflict is to remove the one you do not need. Koda – Kodaloid Jul 26 '17 at 17:40
  • That is frustrating. Whom to blame? – astef Jul 26 '17 at 17:44
1

The best and easiest way to fix this issue, is with a binding redirect, as said. But the versioning looks off.

Simply specify the oldVersion as 0.0.0.0-5.0.0.0, and newVersion as 4.1.1.0

Where 4.1.1.0 is your version, for example.

Jacob Gaiski
  • 516
  • 3
  • 10