[BUG] System.Net.Http NuGet package .NET 4.6.1 assembly conflicts

[rlreis90]

I'm still running into the infamous System.Net.Http NuGet package problem at this moment. Is a fix forthcoming?

I have several .NET 4.6.1 projects which require the System.Net.Http NuGet package (because of package dependency from Azure). If I simply add the package, I get the warning that conflicts occurred. The generated assembly redirects do not solve the issue.

Both of these do not work:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.1.1.2" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

If I use this, the warnings disappear from most projects, but not all:

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.1.1.2" />

Anyone can help shed a light here?

Related:
dotnet/corefx#22781
#17770

[davidsh]

@ericstj can you help with this?

[ericstj]

/cc @AlexGhiondea
You should no longer need the System.Net.Http package on .NET 4.6.1. The latest package has been replaced with .NETStandard 2.0 support libraries which are installed here: C:\Program Files (x86)\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib. The version of the lib there is 4.2.0.0 and this is the redirect you should be using.

It sounds to me like projects are inconsistently getting the support libs (4.2.0.0) vs the last package (4.1.2.0 from nuget package 4.3.3). I know @dsplaisted and @joperezr recently fixed some issues in the SDK around this type of issue. Without more information I can't pinpoint the problem. If possible can you share an isolated repro?

[rlreis90]

I did some testing with a new project and here are the results:

1. Fresh .NET 4.6.1 project
=> ver 4.0.0.0 @ C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.6.1\System.Net.Http.dll
2. Add Microsoft.Azure.DocumentDB.Core package
=> dll ver 4.2.0.0 @ C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll
3. Remove DocumentDB package
=> dll ver 4.1.0.0 @ NuGet dir
4. Update all packages
=> dll ver 4.1.1.2 @ NuGet dir

The weirdest part of it all is if I look at the .csproj file after step 2, this is what will be there:

    <Reference Include="System.Net.Http, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
      <HintPath>..\packages\System.Net.Http.4.1.0\lib\net46\System.Net.Http.dll</HintPath>
    </Reference>

and NOT the 4.2.0.0 path.

I have no idea what's happening here.

If, however, I install the Microsoft.Azure.DocumentDB package (which is the one I actually use), the standard 4.0.0.0 reference remains.
If I search my Add Reference dialog for assemblies, I can't see the version 4.2.0.0.

I'm completely lost here. I keep getting conflicts with Net.Http dll since I have a dependency on Microsoft.Azure.DocumentDB package in a few of my projects (out of a total: 30+ solution).

[ericstj]

I'll explain what's going on.

1. Yep inbox in .NET 4.6.1 the version was 4.0.0.0.
2. MS.Azure.DocumentDP.Core has a ns1.6 implementation, this is what will apply to .NET 4.6.1. 4.6.1 actually changed from supporting ns1.4 -> ns2.0. This change was breaking and in order to address that we had to apply higher versions of the framework assemblies to satisfy that difference. As a result you get the support libraries from Microsoft.NET.Build.Extensions. Here the NET.Http version is 4.2.0.0.
3. Removing this removes the ns1.6 assembly and turns off additions from Microsoft.NET.Build.Extensions. Since you're using packages.config, uninstalling Microsoft.Azure.DocumentDB.Core left its dependencies in the project, which is why you now have the nuget package System.Net.Http (4.1.0.0 from package version 4.1.0).
4. Updating all packages gives you a newer System.Net.Http, package version 4.3.3, assembly version 4.1.2.0. The azure package was using an older version, so you see updates (same update would have been available if you hadn't uninstalled the Azure package).

.csproj file after step 2 ... NOT the 4.2.0.0 path

That's because of the fix I mentioned above. Conflict resolution will prefer the one from Microsoft.NET.Build.Extensions because it is newer.

If, however, I install the Microsoft.Azure.DocumentDB package (which is the one I actually use), the standard 4.0.0.0 reference remains.
If I search my Add Reference dialog for assemblies, I can't see the version 4.2.0.0.

This is the IDE caching information. I think you may need to reload the project in order to see the change. If not it could be a bug with how Microsoft.NET.Build.Extensions is adding references /cc @dsplaisted.

[rlreis90]

Thanks for the reply.
I don't think reloading the test project changed anything.

I think what really confused me is why would just removing DocumentDB.Core dll (uninstalling the package) change the dependencies. Diffing the change, it literally just removes the dll reference from the project.

So I'm trying to figure out the best way to solve this. From what I'm gathering, if I add ns1.6 assembly into all my projects and leave the "default" binding redirect of 4.2.0.0 resolve conflicts, in theory I'll be good?
If so, how can I force my projects to use it? I couldn't figure it out by looking at the project.

[rlreis90]

Hello, @ericstj, @davidsh!
I've solved my problem in a very simple way: I've added NuGet packages to every project in my solution that target the ns assemblies. As per our discussion, that has successfully updated the System.Net.Http dll to 4.2.0.0. For reference, the packages were System.ValueTuple and System.Threading.Tasks.Extensions.

Since I've run into this problem, might I suggest updating the System.Net.Http package to include the 4.2.0.0 dll? This would make it easy to solve the problem by including this package in every project, at least it would be immediately obvious to users.

I'm going ahead and closing the issue.
Thank you for all the help!

[Mek7]

I'm writing this in hope that it will be helpful to someone who has the same problem and doesn't have to waste 3 days like I did.
Our solution has many projects, all targeting .NET 4.6.2 and we use nuget packages too, some of them targeting .NET standard, whatever (this is something we can't influence).
I got the infamous warnings about different assembly versions and such, and no matter what I did, in Properties pane of the System.Net.Http reference, VS stubbornly picked up different DLLs for different projects, and this was the problem. For example:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll
versus
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.6.2\System.Net.Http.dll
The first one is the correct one. So to fix this:

• do not install any System.Net.Http nuget packages (or uninstall if you have them)
• where needed, put binding redirect to 4.2.0.0 to your app/web.config
• make sure your reference in .csproj file is like this:
  <Reference Include="System.Net.Http" />
• where the incorrect path of System.Net.Http.dll is forced by VS (see above), install nuget package System.Memory. This will bring also System.Buffers and System.Numerics.Vectors (and maybe also some others) so if you already have them in some of your projects, make sure they are the same version (upgrade if needed) so that you don't get version mismatch on them.
  Just after installing System.Memory, check your properties of reference System.Net.Http in your project. It should now point to correct path from MSBuild. Then, after you build your solution, warnings are gone.
  Hope this helps someone.

[PaluruSumanth]

Hello, @ericstj, @davidsh!
I've solved my problem in a very simple way: I've added NuGet packages to every project in my solution that target the ns assemblies. As per our discussion, that has successfully updated the System.Net.Http dll to 4.2.0.0. For reference, the packages were System.ValueTuple and System.Threading.Tasks.Extensions.

Since I've run into this problem, might I suggest updating the System.Net.Http package to include the 4.2.0.0 dll? This would make it easy to solve the problem by including this package in every project, at least it would be immediately obvious to users.

I'm going ahead and closing the issue.
Thank you for all the help!

@rlreis90 im facing the same issue, could you please detail how you were able to fix it.

[PaluruSumanth]

/cc @AlexGhiondea
You should no longer need the System.Net.Http package on .NET 4.6.1. The latest package has been replaced with .NETStandard 2.0 support libraries which are installed here: C:\Program Files (x86)\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib. The version of the lib there is 4.2.0.0 and this is the redirect you should be using.

It sounds to me like projects are inconsistently getting the support libs (4.2.0.0) vs the last package (4.1.2.0 from nuget package 4.3.3). I know @dsplaisted and @joperezr recently fixed some issues in the SDK around this type of issue. Without more information I can't pinpoint the problem. If possible can you share an isolated repro?

@ericstj even though i have system.net.http.dll at C:\Program Files (x86)\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib. it is being picked up from packages.

[ericstj]

The assembly from Microsoft.NET.Build.Extensions is only referenced if needed as determined by https://github.com/dotnet/sdk/blob/6d67b5fde471245e0ed0a83e73517091d0728be2/src/Tasks/Microsoft.NET.Build.Extensions.Tasks/msbuildExtensions/Microsoft/Microsoft.NET.Build.Extensions/Microsoft.NET.Build.Extensions.NETFramework.targets#L24.

If you feel you have an issue please open a new issue with full repro steps. There are many different problems that could cause issues related to loading of System.Net.Http.