runtime: System.Net.Http redirect errors in VS 15.3.0

As requested by @karelz a dedicated bug to the issue mistakingly reported in dotnet/corefx#22781.

Story:

Existing .NET 4.6 application, including System.Threading.Tasks.Dataflow 4.7.0 nuget package and System.Net.Http 4.3.2 package, redirects for System.Net.Http are configured
Nuget offers update of Dataflow to V 4.8.0
After update, redirects for System.Net.Http warn that I should redirect to V 4.2.0 Note: If I don’t touch the nuget update at all, no build errors occur

Steps to reproduce in a small repro:

Create .NET 4.6 project
Add reference to Nuget System.Net.Http (V 4.3.2) package
Add binding redirect to

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

Compile (no warnings)
According to Project references the Assembly version of System.Net.Http.dll is 4.1.1.1
Add reference to one of (there are probably more packages)
- System.Threading.Tasks.Dataflow nuget (V4.8.0)
- System.Buffers (V4.4.0)
Compile

Expected result:

No warnings

Actual result:

Consider app.config remapping of assembly “System.Net.Http, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” from Version “4.1.1.1” [c:\users\tornhoof\documents\visual studio 2017\Projects\NetHttpRepro\NetHttpRepro\bin\Debug\System.Net.Http.dll] to Version “4.2.0.0” [C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\System.Net.Http.dll] to solve conflict and get rid of warning.

Workaround:

Do what it suggests and replace the redirect with

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <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>      
    </assemblyBinding>

I don’t know why the build suddenly uses a library from the VS program directory and not from the NuGet packages. Note: Of the packages released on August 11th, not all are affected, e.g. System.Diagnostics.DiagnosticSource V4.4.1 does not show the behaviour.

[EDIT] Fixed bullet points formatting to improve readability by @karelz

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 3
Comments: 50 (19 by maintainers)

Most upvoted comments

To help frame the audience of this proposed “single upgrade doc”:

Yesterday my solution compiled and ran correctly
Today I upgraded to VS 15.3.0
Today it still compiles, but I have all kinds of warnings that weren’t there yesterday:

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

And if I try running, I get:

System.IO.FileLoadException: ‘Could not load file or assembly ‘System.Net.Http, Version=4.1.1.1, 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)’

This is the situation a lot of people are in right now, and since we can’t downgrade to 15.2, we’re stuck unless we can figure out how to resolve these issues.

+14

vinniep79 on Aug 17, 2017

@ericstj Thank you for the explanation. My main issue through all of this is the lack of guidance. I could not find anything in the release notes detailing the tooling changes and what should be done to move from tooling v1 to v2. It’s still not entirely clear to me what the correct solution is. Are we to remove the nuget packages? or are we to keep them and just update the binding redirects to use the versions now provided with VS 15.3? Some clear upgrade documentation would have gone a long way here.

+10

mscrivo on Aug 17, 2017

very nice, thank you for all the quick and helpful responses! Combining all these instructions/workarounds into a single upgrade doc would probably go a long way to avoid having other people become super frustrated by this. I can’t count how many times I’ve had to do full cleans and rebuilds of our solution to get through this.

mscrivo on Aug 17, 2017

The reason this happens automatically on upgrade is because you get the new NuGet. NuGet made a breaking change in order to map netstandard2.0 to net461. This is essentially the price we had to pay to bring NETStandard2.0 back to net461 and not just some future .net framework. Previously net461 only supported netstandard1.4. Now net461 can suddenly start to load ns1.5, ns1.6 assemblies which are already out there (some of which have higher versions than the net461 assemblies in the same packages). To react to the breaking change we had to provide updated assemblies for net461 and later that make up netstandard. This is done through build targets.

The reason for the warnings in the solution explorer is due to this issue: https://github.com/dotnet/sdk/issues/1499

You only see that for projects using packages.config, so you can either update to packagereference, or follow the workaround I listed in the issue. The warnings are innocuous and merely present in the IDE, but can be annoying. An alternative workaround is to remove those references from your project.

The reason for the runtime error is due to missing bindingRedirects. Projects using automatic binding redirects will not see this error. BindingRedirects need to be updated because the assembly versions were updated (the ones we automatically inject). You’d actually see this bug even if we did nothing since it’ll result from the nuget breaking change. The fix here is to enable automatic bindingRedirects if you can, or update your config files if you cannot.

I had a discussion with @terrajobst and we’ll work on a doc or blog post to help folks out here.

ericstj on Aug 17, 2017

Docs and a viable upgrade path and what-do-I-do-right-now-to-get-my-project-to-compile would be greatly appreciated. There are just so many rough edges on the .net core (don’t even make me try mentioning the version - I simply can’t 😉) tooling right now… It’s really, really difficult trying to move slowly and smoothly to .net core from net461.

erikbra on Sep 11, 2017

Aa post mortem from my side: I basically followed @ericstj’s recommendation:

Removed my manual binding redirects from every project and added:

<PropertyGroup>
  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>

everywhere. GenerateBindingRedirectsOutputType was new in my projects, see https://github.com/Microsoft/msbuild/issues/1310 for that problem.

I converted all my projects to remove the packages.config and use PackageReference instead to get around the problem with SpecificVersion.
Manually upgrade my NuGet assembly in TFS to 4.3 beta, to be able to restore .NET Standard 2.0 dlls (can’t find the NuGet issue for that anymore).

Bottom line, quite a bit of work involved just for updating to VS 15.3 😉

Tornhoof on Aug 21, 2017

@ericstj Sorry, yes it happens with .NET 4.6.1 and 4.7.0 (didn’t test any others though, but I guess 4.6.2 is the same). I understand your solution, which is basically equivalent to my workaround.

When a netstandard2.0 assembly is referenced in the desktop project we automatically add all the assemblies needed to make it work: no more package references. When we do this we add a newer System.Net.Http.dll than what you were previously using, since that is part of netstandard2.0.

Thank you for your explanation, but I’m not certain if that behaviour is valid or even useful. Suddenly my builds are not reproducable anymore, because suddenly the libraries are taken from the VS installation directory and not my NuGet package cache directory anymore. This basically introduces another error source to my builds, because now I need to also track down libraries from installation directories which are neither part of the full framework nor any of my NuGet packages. Example: You ship 15.3.1 (the next update to VS 2017 15.3) which includes System.Net.Http (.NET 4.6.1 lib V4.2.1). Now the developer has that version installed, the build environment might not. So the developer will debug problems with a different library version than the production build. To make certain, that I don’t run into that problem, I enabled Specific Version ony my package references to make certain I don’t suddenly get an unknown version.

Please rethink that automatic assembly resolving or simply publish the updated NuGet packages.

@rainersigwald Thank you for tracking down the pull request, I think @ericstj has indeed reproduced my problem, my message is just the Build Log output, which appears to be a bit different.

Tornhoof on Aug 16, 2017

OK thanks for that clarification @karelz, I appreciate your time! I’ll definitely keep monitoring this issue and keep an eye on both technologies.

alexangas on Aug 31, 2017

Wrote a program, which parses packages.config and tries to replace as many old project references as possible. Had to manually fix my Web Projects, because of some weird Import statements in the csproj.

https://gist.github.com/Tornhoof/3710df4711900339d69a1cc99abf3ec2

Tornhoof on Aug 21, 2017