Standard: Understanding NETStandard.Library as a dependency in my nuspec

[jnm2]

Should a NETStandard.Library dependency appear in a nuspec?

What does it do to projects that reference the nupkg versus not having it in the nuspec? If my netstandard1.6 library chooses to depend on 1.6.1, doesn't that force any dependent library to also depend on 1.6.1+? Is that a good thing and is that why you'd put it in a nuspec?

Out of 1.6.0, 1.6.1, 2.0.0, and 2.0.1, the SDK picks 1.6.1 and 2.0.0 to reference for netstandard1.6 and netstandard2.0. Why not 2.0.1 for both?

Is there a changelog that summarizes the differences in 1.6.1, 2.0.0 and 2.0.1?

Are there docs that answer these questions? This is the only information I've been able to glean so far which hints that keeping it in the nuspec is correct, but it doesn't answer any of my other questions:

(https://docs.microsoft.com/en-us/nuget/guides/create-net-standard-packages-vs2017#package-the-component)

[weshaggard]

Hopefully https://github.com/dotnet/standard/blob/master/docs/faq.md#should-i-reference-the-meta-package-or-should-i-reference-individual-packages helps to answer your question somewhat. But in general with the move to NS2.0 we don't expect there to be package dependencies in nuspec's for libraries targeting NS.

Out of 1.6.0, 1.6.1, 2.0.0, and 2.0.1, the SDK picks 1.6.1 and 2.0.0 to reference for netstandard1.6 and netstandard2.0. Why not 2.0.1 for both?

It general we try to reference the latest for the target framework. The SDK is being updated to target 2.0.1 but it just hasn't released yet.

Is there a changelog that summarizes the differences in 1.6.1, 2.0.0 and 2.0.1?

There isn't really a change lot for these anywhere that I'm aware of. In general 1.6.0 was related at the same time as .NET Core 1.0 and so targets nuget packages from that time and 1.6.1 targets packages shipped with .NET Core 1.1. With 2.0 we are now shipping it independent from .NET Core releases so it ships from this repo now. 2.0.1 was servicing release for 2.0 you can see the included fixes at https://github.com/dotnet/standard/issues/550.

[jnm2]

@weshaggard Great, thanks!

1. We're moving away from using packages to describe our platforms, including .NET Standard.

This means, you'll not have to reference any NuGet packages for .NET Standard anymore. You expressed your dependency with the lib folder, which is exactly how it has worked for all other .NET platforms, in particular .NET Framework.

However, right now our tooling will still burn in the reference to NETStandard.Library. There is no harm in that either, it will just become redundant moving forward.

This makes me want to start using <PackageReference Update="NETStandard.Library" PrivateAssets="all" /> to suppress it from the nuspec and to remove the NETStandard.Library dependency from manually crafted nuspec files such as NUnit's. It seems to have two benefits: reduce noise which confuses people, and make clashes with consuming projects less likely. Is there any downside to this?

[weshaggard]

cc @dsplaisted @emgarten
I thought the tooling was already filtering out NETStandard.Library at least 2.0 and up, for nuget pack commands. I'm not entirely sure what PrivateAssets="all" implies in all cases so I'm not sure if that will have other consequences or not.

[emgarten]

@rohit21agrawal is netstandard.library included by default in new packages?

[rohit21agrawal]

i just verified by packing a new .netstandard2.0 project, and the dependency is not included by default if you pack.

[jnm2]

Alright, if one of my targets is netstandard1.x, I should continue with <PackageReference Update="NETStandard.Library" PrivateAssets="all" />; otherwise, nothing needs to be done?

[dasMulli]

@jnm2 depends on who is using the library.
If someone with VS 2015 (without .net standard build extensions installed) pulled down that library, they would be missing the libs brought in by the NETStandard.Library package. In VS 2017 / build extensions, the DLLs brought in via the individual NuGet packages are trimmed out of the build and replaced with DLL files shipped as part of the tooling.

I had good experiences conditionally setting NetStandardImplicitPackageVersion in the csproj file:

<NetStandardImplicitPackageVersion Condition=" '$(TargetFramework)' == 'netstandard1.3' ">1.6.0</NetStandardImplicitPackageVersion>

That way each .NET Core 1.0/1.1 project can use the version they include (1.6.0 for 1.0, 1.6.1 for 1.1) without running into issues like https://github.com/JamesNK/Newtonsoft.Json/issues/1252 and any netstandard2.0 slice won't be affected and still not contain a dependency.

Tried to give the current situation a write-up at https://stackoverflow.com/a/47366401/784387

[jnm2]

So if I decide not to support VS2015 without build extensions, I should use <PackageReference Update="NETStandard.Library" PrivateAssets="all" />.

Otherwise, I should depend on the lowest possible version number to make sure the package works in VS2015 without build extensions, without the possibility of conflicts:

<NetStandardImplicitPackageVersion Condition=" '$(TargetFramework)' == 'netstandard1.3' ">1.6.0</NetStandardImplicitPackageVersion>
<NetStandardImplicitPackageVersion Condition=" '$(TargetFramework)' == 'netstandard2.0' ">2.0.0</NetStandardImplicitPackageVersion>

Since leaving out the nuspec dependency for netstandard2.0 would make it unusable with VS2015 without build extensions.

Does this sound like the ideal scheme?

[dasMulli]

For 2.0, it shouldn't matter (as long as you are using a recent .NET SDK). It is only needed to not force 1.6.1 implementation DLLs onto platforms containing 1.6.0 versions. (which isn't that bad now since both are LTS now, bet see linked newtonsoft.json issue).

For netstandard2.0, you don't have to specify/pin NetStandardImplicitPackageVersion - the SDK will emit an implicit package reference to a "good" version and no nuspec dependencies will be added default (Which is the same as PrivateAssets="All").

[jnm2]

@dasMulli Will a netstandard2.0 nupkg without the NETStandard.Library dependency work with VS2015 without build extensions? If I don't make netstandard2.0 work for VS2015 I'll be less likely to make netstandard1.6 work for VS2015– and I'm back to preferring to suppress any nuspec dependency on NETStandard.Library.

[dasMulli]

I believe the latest NuGet versions for 2015 that understand netstandard2.0 will refuse to install it without the extension installed.

[jnm2]

Cool. My questions are answered and I'm grateful for your time.