In a large solution with 52 projects (all net462), the latest version of some of our dependencies are now only built for NET standard. Therefore they depend on the NuGet pac
In the default project template System.Net.Http
is added to the project as a reference, not as a nuget package.
In both of your solutions (4.6.1 and 4.7.1):
Project ClassLibrary
has a dependency on System.Net.Http
as a nuget package.
Project ConsoleApp1
has a dependency on System.Net.Http
as a simple reference from .NET Framework
So, the issue is not related to Target Framework version.
To fix the issue add the same version of
System.Net.Http
as a nuget package to all projects (where it is used).
Right-click the solution in Solution Explorer and choose Manage NuGet Packages for Solution...
Switch to Installed
tab
Find System.Net.Http
in the list, select it.
Check current state:
Install the same version of the package (4.3.0 in your case) to ConsoleApp1
project.
Check the result:
Done.
Also, it's good practice to have package versions consolidated in your solution. Instead, you could have version conflicts during build time. Or, which is worse, runtime error like MethodNotFound
because of binding redirect to another version of the dependency.
The reason for the problem with System.Net.Http
is described here:
Broken System.Net.Http 4.1.1-4.3.0 post-mortem in section How to prevent such situation in future? 2.1
As a result we identified 2 problematic OOB packages, which are not leaf-nodes in the platform itself, and have dependency from the platform on them - System.Net.Http and System.IO.Compression.
It means that the same System.Net.Http
library is shipped within .NET Framework and as OOB (out-of-band) nuget package. And some nuget packages could reference nuget version of it. And here it comes the problem that I described at the very beginning.
So, you don't have to fix references to all System.*
libraries. Only for these two: System.Net.Http
and System.IO.Compression
.