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

Created on 3 Oct 2018 · 7Comments · Source: dotnet/runtime

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

area-Infrastructure-libraries packaging question

Source

BrainSlugs83

👍2

Most helpful comment

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. :-)

BrainSlugs83 on 4 Oct 2018

👍2 ❤1

All 7 comments

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.

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.

GSPP on 3 Oct 2018

❤2 👍1

@joperezr

davidsh on 4 Oct 2018

👍1

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

karelz on 4 Oct 2018

👍1

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.

joperezr on 4 Oct 2018

👍1

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

BrainSlugs83 on 4 Oct 2018

👍2 ❤1

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.

StingyJack on 19 Oct 2018

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!