search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.73k stars 1.07k forks source link

Libraries targeting .NET Standard 1.x bring in a version of System.Net.Http package which is broken on Full Framework #2261

Open dsplaisted opened 6 years ago

dsplaisted commented 6 years ago

Libraries that target .NET Standard 1.x reference the NETStandard.Library package version 1.6.1. This package in turn depends version 4.3.0 of the System.Net.Http package, which has serious issues when used on .NET Framework.

Potential solutions:

ericstj commented 6 years ago

See also https://github.com/dotnet/corefx/issues/19936 https://github.com/dotnet/corefx/issues/15735

terrajobst commented 6 years ago

Seems the cleanest solution is

Create a NETStandard.Library 1.6.2 package with the dependency on System.Net.Http bumped to 4.3.1, and reference version 1.6.2 of NETStandard.Library for .NET Standard 1.x projects

weshaggard commented 6 years ago

Create a NETStandard.Library 1.6.2 package with the dependency on System.Net.Http bumped to 4.3.1, and reference version 1.6.2 of NETStandard.Library for .NET Standard 1.x projects

That would be the smallest delta code change but then we would need to deal with any other places that currently reference 1.6.1 and update them as well.

Personally I kind of like moving to the latest version so the 2.0.3 NETStandard.Library version. It has a unique set of package dependencies already for each target framework so the difference in package dependencies should be on par, if not better then what is in 1.6.1. @ericstj can you think of any issues with using that approach?

ericstj commented 6 years ago

I guess it might get a little more complicated to ship some future servicing fix, we would need a new standard repo build rather than just corefx. That’s minor but something to think about.

dsplaisted commented 6 years ago

Personally I kind of like moving to the latest version so the 2.0.3 NETStandard.Library version. It has a unique set of package dependencies already for each target framework so the difference in package dependencies should be on par, if not better then what is in 1.6.1. @ericstj can you think of any issues with using that approach?

The reason we didn't do this (use NETStandard.Library 2.0.x for projects targeting .NET Standard 1.x) in the 2.0 release of the SDK was that for projects targeting .NET Standard 1.x, there was a reference to NETStandard.Library 1.6.1 that got burnt into the resulting NuGet package. We didn't want that dependency of the produced package to be bumped to version 2.0.x when you updated the SDK, because that would have made the new package incompatible with the old SDK (you'd get package downgrades). We also didn't want to remove the NETStandard.Library package dependency when you updated to a new version of the SDK, as then when the package was referenced from .NET Framework projects, it wouldn't automatically get the implementations / facades needed to make .NET Standard 1.x work.

Given the severity of the System.Net.Http issue, I think we can reconsider these decisions. For example, we could switch to using the latest version (2.0.3) of the NETStandard.Library package in all cases, and not have it show up as a dependency of the package when a project is packed, with guidance on how to opt back in to having the dependency show up on the package if need be. We should discuss the various options and their pros and cons before changing something though.

terrajobst commented 6 years ago

So long we only burn in the reference to the package for .NET Standard 1.x, I'm fine with either fix.