Getting super weird binding redirect behavior with System.* NuGet Packages

[BrainSlugs83]

As soon as I add any of the latest NuGet packages (System.Net, System.Runtime, Microsoft.Bcl*, etc.) -- Visual Studio starts to warn me that:
1.) Basically every other project in my solution / down stream of that project needs to add that NuGet package also -- okay, that's not terrible, just annoying... (but more problematic because of issue no. 2, below):
2.) Every single downstream project suddenly wants me to add a ton of binding redirects, everything to 4.2.0.0 -- problem is -- this suggestion is wrong, and breaks those projects at run time!

RE no. 2: If I leave out the binding redirects, everything compiles and runs fine. -- But if I put in the binding redirects, the app fails at runtime with either FileNotFoundExceptions or TypeLoaderExceptions.

I'm using the latest .NET 4.7.2 SDK, and Visual Studio 2017 (15.8.5).

So two questions:
1.) Is there anything I can do to make the warning go away without putting in the erroneous binding redirect?

2.) Is there any way to shelter downstream projects from these false warnings automatically? (because one of the projects is an internal NuGet package that we use that, due to both issues no. 1 and 2 above, has caused the consumers to break their projects as well -- because Visual Studio told them to add a binding redirect, and they did, and it also broke for them.)

[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
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.

[davidsh]

@joperezr

[karelz]

@BrainSlugs83 can you please share repro steps? I cannot reproduce it with library and console app both targeting 4.7.2. Neither with simple .NET Standard 2.0 lib with explicit System.Runtime 4.3.0 dependency.

[joperezr]

which framework are you targeting? If you could give a simple repro that would be the best so we could diagnose what is going on. FWIW, I don't believe the binding redirects are wrong. We add those because your app will need to use specific assemblies that will ship with your app in order to be able to consume .NET Standard based components at runtime. Those specific assemblies are supposed to get dropped into your bin folder along with the app, so the binding redirects will only force to use those instead of the ones inbox.

[BrainSlugs83]

Both 4.7.2 and .NET Standard 2.0. -- I can't share with you my verbatim code base due to NDA, but this eventually happens in every solution I work on at some point -- maybe not day 1, but after enough projects get into the solution (even with all NuGet packages consolidated), this eventually happens, and it's always the Microsoft.* or System.* packages that want the bad binding redirects.

I will try this weekend to replicate a minimal code solution where the issue reproduces.

FWIW, I don't believe the binding redirects are wrong...

I know -- it looks correct to me also -- but the DLLs from the NuGet package are definitely getting copied to the output folder, and Console Apps, ASP.NET apps, and Worker Role Apps will all fail when those binding redirects are added (and deleting them fixes the issue). -- So, something is clearly not working as intended. -- I'll help you guys track down some repo steps, just give me a couple of days. :-)

[StingyJack]

All these crazy binding redirects are happening with 4.6.2 as well, and I'm only using a nuget package that only has a netstandard2.0 dll. I have no projects that compile and target anything other than net452 and net462.

@karelz - there should be a feedback collection recording on this. If not and you want/need one, set the item to "Need more info" and ping me and I can re-record. I would comment on the solution given there (but I cant) to say that it cannot be "by design" to start popping up massive warnings in the error list that recommend making a breaking change to a program when a nuget package is updated and that package's author decided to go netstandard.

[antibarbie]

We are using 4.7.2 and had to do these things to prevent the infamous error "System.Net.Http 4.2.0.0 not found" :

• change from packages.config to PackageReference
• remove the infamous Nuget <PackageReference "System.Net.Http"> in the infected projects
• add a <Reference> to System.Net.Http

Then, the bindingreference are no longer re-generated in the .exe.config files ! Yeah!

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.