Advantages of netcoreapp2.0 vs netstandard2.0 for a library project

Jon Bates picture Jon Bates · Aug 24, 2017 · Viewed 8.1k times · Source

I have a preexisting dotnet 4.6.2 solution that comprises of two outer projects (to be ported at the same time) and a shared core library.

I need to choose the core assembly's TargetFramework, which could either be netcoreapp2.0 or netstandard2.0.

Since it won't be executable, or referenced by any external project, are there any advantages one way or the other?

Answer

Mathieu Renda picture Mathieu Renda · Aug 24, 2017

They differ in nature:

Each version of the .NET Core Librairies implements (at least) a given version of the .NET Standard, and a complete table can be found in the .NET Standard documentation. Right now, the latest versions are in sync (2.0 - 2.0), but this hasn't been and won't always be true.

The .NET Core Libraries are actually always a superset of the APIs defined in the corresponding version of the .NET Standard. There are always types and members available in the .NET Core Libraries, which are not (yet?) part of the .NET Standard. Microsoft publishes namespace-by-namespace comparisons of the available APIs.

Your library might use an API that has not yet been standardized in the .NET Standard (or might never be), but is already available in .NET Core Libraries. As an example, you might use types from the System.Drawing namespace, that will soon be available in the .NET Core Libraries, but won't be part of the .NET Standard 2.0.

So, by choosing netcoreapp2.0 over netstandard2.0, you gain access to a larger API, at the expense of compatibility.

On a general note, you should always try to target the most portable framework (here, netstandard).

If it is not an option for you, the next best thing would be to cross-target multiple frameworks from a single library, as explained here: How do you multi-target a .NET Core class library with csproj?. Many .NET Core APIs missing from the .NET Standard are also present in the (full) .NET Framework.