Standard: FAQ: Advice for using NETStandard.Library package vs single packages

[GerjanOnline]

As far as I understand NETStandard.Library is just a meta package that is used for the compiler / api surface.

https://www.nuget.org/packages/NETStandard.Library

Here it is also visible which packages comes with what version.
But now my question is, and maybe that is one for the FAQ:

What if I only need, say, 3-5 packages, should I still reference the whole NETStandard.Library? Or can/should I just ref those 3-5 single packages?

I've heard/read conversations that MS is recommending always using NETStandard.Library, why? For updating probably, security issues etc.

[weshaggard]

@GerjanOnline this is an excellent question, one which we are shifting our recommendation on. In the past we were recommending for library packages people reference the smaller granular packages in order to help maximize current and future portability. However we have learned that all the granular packages have causes a number of issues such as package graph explosion and many complexities in understanding which package versions could actually work with each other. With our new direction for .NET Standard 2.0 all the .NET platforms will align to a standard set of APIs and so referencing anything less granular then the .NET Standard package isn't very interesting as all the APIs will be part of the underlying platforms.

So while NETStandard.Library 1.6.X is a meta-package (i.e. references a set of other packages), in the 2.X version it will become a flat package and contain the reference assemblies directly in the package. For this reason our recommendation would be to just reference NETStandard.Library now as opposed to the individual packages.

Hope that helps.

[mellinoe]

What is our plan for dealing with dependency bloat in standalone applications? "One big package" is good from a referencing standpoint, but not from a modularity standpoint. It'll be much harder to ship a slim set of dependencies when I just have one big reference. I'm sort of skeptical of any "post-build dependency trimming" like we've talked about in the past, just because it's never materialized.

[weshaggard]

There isn't any concrete plans/designs yet but it will likely be "post-publish dependency trimming" for standalone applications, for shared applications it isn't needed.

[terrajobst]

@mellinoe:

What is our plan for dealing with dependency bloat in standalone applications? "One big package" is good from a referencing standpoint, but not from a modularity standpoint.

The thinking is basically that these are separate concerns. Having more packages doesn't really help our bloat of standalone apps; the idea was that we'll smartly copy only those assemblies that are needed. But for a really optimized footprint we'd need something like .NET Native's linker + tree shaker. And once you look at optimizing at that level, packages boundaries are irrelevant.

[terrajobst]

@GerjanOnline:

I'll upload a draft of our packaging doc very soon. That will include layout and reference graphs.

[jkotas]

I'm sort of skeptical of any "post-build dependency trimming" like we've talked about in the past, just because it's never materialized.

@erozenfeld @russellhadley are looking into materializing it this time. They should share the plan soon.

[russellhadley]

@mellinoe - Yes we're looking at a post-build assembly level "link" tool. We're still writing up our plan but we expect to share it next week with the community. Stay tuned. :)

[StefH]

@terrajobst
What is the final conclusion now ?

Include the full NETStandard.Library for a NETStandard 1.0 project or just the dependencies you need?

Note that the generated NuGet package does automatically include the NETStandard.Library, even if I don't specify.

[weshaggard]

The guidance should be to reference NETStandard.Library package reference as opposed to the individual references as that will align better with our future direction.

[weshaggard]

This was address by https://github.com/dotnet/standard/pull/253.