I have read about the difference between .NET Standard and .NET Core, but I really don't know what the difference is, or when to choose a .NET Standard library project and when to choose a .NET Core library project.
I have read that .NET Standard is to ensure that a set of APIs are always available, no matter the platform used (as long as that platform is compatible with the .NET Standard version that I have chosen). If I'm not mistaken, this means that I can create a class library of .NET Standard and then use it on any platform that is compatible with the .NET Standard version that I have chosen.
With .NET Core, I have read that it is intended for cross-platform use too, so if I choose a .NET Core library it seems that I can use it on many platforms too, just like .NET Standard.
So at the end, I don't see the difference. When should I use which? What is the difference between them?
I will try to further clarify your doubts and extend Jon Skeet answer.
.NET Standard is a specification, so a library compiled for a specific .NET Standard version can be used in different .NET Standard implementations.
As said in my other comment, a good analogy for the relationship between .NET Standard and other .NET Standard Implementations (.NET Core, .NET Framework, etc) is this gist by David Fowler: .NET Standard versions are Interfaces
, while frameworks are implementations of those interfaces.
This simplified diagram may help to understand this relationship:
Anything targetting NetCore10
has access to INetStandard15
APIs and NetCore10
specific APIs (such as DotNetHostPolicy
).
Of course this library cannot be used in different INetStandard15
implementations (NetCore10
is not convertible to NetFramework462
or Mono46
).
If you, instead, need access only to INetStandard15
APIs (and target that specification instead of a concrete framework) your library may be used by any framework which implements it (NetCore10
, NetFramework462
, etc.)
Note: in the original analogy David Fowler used interfaces for both .NET Standard versions and frameworks implementations. I believe that using interfaces and classes is, instead, more intuitive and better represents the relationship between specifications and concrete implementations.