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. I originally opened two issues about this with dotnet/standard:

• "Could not load System.Runtime.dll" because it was not copied to the output folder #887
• A package referencing just NETStandard causes invalid binding redirects on .NET 4.7.2 in a web application #941

I was told that an internal NuGet issue exists to track this work and that I might create a public GitHub issue to publicly track this. I am hereby doing that.

To summarize, there are a few suspicious points about this:

• Wrong binding redirects are added
• System.Net.Http is installed when it should not be
• A superfluous install of System.Net.Http should be benign
• Merely opening Visual Studio causes wrong DLLs to be copied to bin which then prevent the application from running. A normal build (after clearing bin/obj) does not do that and that works. This might be unrelated but I'm adding it here anyway to be safe (Design time build causes "Cannot load a reference assembly for execution." #936).

All of this is on .NET 4.7.2, VS 15.8.7, Windows 7. I also repro'ed some of it on a clean Windows 10 VM with VS 15.8.8.

[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
dotnet/standard#481
dotnet/standard#567
dotnet/standard#558
dotnet/standard#887
dotnet/standard#891
https://github.com/dotnet/corefx/issues/32610
https://github.com/dotnet/corefx/issues/30642
https://github.com/dotnet/corefx/issues/32757
dotnet/standard#895
dotnet/standard#877
dotnet/standard#521
dotnet/standard#295
dotnet/standard#476
dotnet/standard#184
dotnet/standard#936
dotnet/standard#941
https://github.com/dotnet/corefx/issues/33148
#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.

[rrelyea]

@GSPP does this still repro on 15.9 and 16.1?
Sorry for your troubles

[GSPP]

I just tested on the latest 2017 and it still reproduces. In particular it is enough to merely open the solution to get reference assemblies copied into bin so that my app won't start (dotnet/standard#936). This is the most annoying of the bugs.

Please take a look at these issues. I believe they affect a lot of developers because they are so easy to reproduce. The web and this issue tracker are full of reports. If you do a web search for a few of the error messages you will finds masses of cases.

These issues seem severe and should be prioritized. Am I misjudging the impact?

Do you need help in reproducing? The issues that I opened have repro instructions.

Pinging people from related issues: @joperezr @wtgodbe @terrajobst @karelz

[karelz]

@GSPP which of the bugs still exist and reproduced on .NET 4.7.2 / 4.8?
The list above is long and as we said in other places, we believe most (maybe all) of them are addressed in 4.7.2 and 4.8.

[karelz]

BTW: There are still about 7 bugs opened from the list above (incl. this one). I would recommend to consolidate them into 1 clearly described problem with simplified repro on 4.7.2 / 4.8.

[GSPP]

I might make another run at this in the future. It is a good point that I need to test 4.8. 4.7.2 + the latest VS17 definitely does not contain a fix for dotnet/standard#936. I'd need to test the other issues as well.

[GSPP]

I can still reproduce dotnet/standard#936 on 4.8, latest VS17 and in a clean VM. It's unlikely to be a configuration issue with the machine.

[karelz]

@GSPP thanks! Note that we were not able to reproduce that repro: dotnet/standard#936 (comment) ... so I have suspicion there is something more fishy happening on your side (maybe the project does not target 4.7.2, or something like that). Anyway, let's dig into that one.
cc joperezr

[GSPP]

I'm certainly willing to help you reproduce. I also do not exclude the possibility of user error on my part but I tried to be careful (that's why I used the clean VM). In any case I believe I am using a supported configuration because I am really not doing anything advanced.

Can you give me a list of things I need to reproduce? Is it just 936? I has been a while since I touched this problem area.