A package referencing just NETStandard causes invalid binding redirects on .NET 4.7.2 in a web application

[GSPP]

There seems to be an issue that adds bad binding redirects to web.config and it also leads to System.Net.Http being erroneously installed. I'm not sure with my diagnosis here but there seems to be some issue. This issue uses the UAParser NuGet package but UAParser is not at fault. It merely references NETStandard so I'm using this package to demonstrate the issue. This is on .NET 4.7.2, VS 15.8.7, Windows 7.

The core of the repro is this:

1. Create an MVC web app.
2. Create a second library project (might not be needed to repro).
3. Install UAParser into both projects.
4. Uncomment the telemetry module to avoid this issue.
5. Use UAParser in code.

The app crashes like this:

System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.'

FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

In the web.config file there are binding redirects like this one:

      <dependentAssembly>
        <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0" />
      </dependentAssembly>

If this one and a few others are commented out the app runs. The redirects appear inappropriate because they do not specify the version number that is installed on the machine (4.0.0.0 I believe).

I also note that System.Net.Http was installed. According to this comment this should not be done. So I manually uninstalled it, deleted bin/obj, commented in the binding redirects and tested. This did not change anything.

I'm not sure what exactly is broken here but I do not believe that UAParser does anything wrong here. It only references NETStandard which can't be wrong according to my understanding.

---

---

We are experiencing this issue in a production application. This forces us to manually undo the faulty binding redirects after NuGet operations.

BindingRedirectsRepro.zip

[GSPP]

I'm tracking related issues and information in a list. They are related to System.Net.Http, System.Runtime, System.IO, System.ValueTuple, System.Buffers and others.

https://github.com/dotnet/corefx/issues/32587
https://github.com/dotnet/corefx/issues/32561
#481
#567
#558
#887
#891
https://github.com/dotnet/corefx/issues/32610
https://github.com/dotnet/corefx/issues/30642
https://github.com/dotnet/corefx/issues/32757
#895
#877
#521
#295
#476
#184
#936
#941
https://github.com/dotnet/corefx/issues/33148
NuGet/Home#7440
https://github.com/dotnet/corefx/issues/31532
https://github.com/dotnet/corefx/issues/22781
https://github.com/dotnet/corefx/issues/23306
https://github.com/dotnet/corefx/issues/29622
https://github.com/dotnet/corefx/issues/9846
https://github.com/dotnet/corefx/issues/17522
https://github.com/dotnet/corefx/issues/25773

All of these have the same very few underlying issues.

.NET 4.7.2 helps with some but not all of these. You can look at my comments on some of these issues for some ideas on how to work around those problems. I also have a central list of ideas to try.

[joperezr]

I'm pretty sure that this is the same issue that you logged here #887. It might be caused by referencing a different package, but the same issue is happening underneath. That is that NuGet package manager will add wrong binding redirects into your App.config. As suggested in the other issue, a workaround for this is to instead use PackageReference instead of using the default NuGet package manager.

[GSPP]

@joperezr OK, to me it seemed different. Then, feel free to close this. Btw, why is #887 closed? Is there nothing to fix?

[joperezr]

We closed that one because the issue is external. We have an internal issue with NuGet package manager that is tracking this, but if you’d like to be able to track the progress for that, you could log a github issue at nuget/home repo.

[GSPP]

@joperezr Thank you, I have done that (NuGet/Home#7440).