In Visual Studio, there are at least 3 different types of class library you can create:

  • Class Library (.NET Framework)
  • Class Library (.NET Standard)
  • Class Library (.NET Core)

* Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

* Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.


Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

As a quick resume, we can say that:

.Net Framework and .Net Core are two different implementations of the .Net runtime. Both Core and Framework (but especially Framework) have different profiles that include larger or smaller (or just plain different) selections of the many APIs and assemblies Microsoft has created for .Net, depending on where they are installed and in what profile. For example, there are some different APIs available in Universal Windows apps than in the “normal” Windows profile. Even on Windows, you might have the “Client” profile vs the “Full” profile. Additionally, there are other implementations (like Mono) that have their own sets of libraries.

.Net Standard is a specification for which sets of API libraries and assemblies must be available. An app written for .Net Standard 1.0 should be able to compile and run with any version of Framework, Core, Mono, etc, that advertises support for the .Net Standard 1.0 collection of libraries. Similar is true for .Net Standard 1.1, 1.5, 1.6, 2.0, etc. As long as the runtime provides support for the version of Standard targeted by your program, your program should run there.

A project targeted at a version of Standard will not be able to make use of features that are not included in that revision of the standard. This doesn’t mean you can’t take dependencies on other assemblies, or APIs published by other vendors (ie: items on NuGet). But it does mean that any dependencies you take must also include support for your version of .Net Standard. .Net Standard is evolving quickly, but it’s still new enough, and cares enough about some of the smaller runtime profiles, that this limitation can feel stifling. (Note a year and a half later: this is starting to change, and recent .Net Standard versions are much nicer and more full-featured).

On the other hand, an app targeted at Standard should be able to be used in more deployment situations, since in theory it can run with Core, Framework, Mono, etc. For a class library project looking for wide distribution, that’s an attractive promise. For a class library project used mainly for internal purposes, it may not be as much of a concern.

.Net Standard can also be useful in situations where the SysAdmin team is wanting to move from ASP.Net on Windows to ASP.Net for .Net Core on Linux for philosophical or cost reasons, but the Development team wants to continue working against .Net Framework in Visual Studio on Windows.

This is how Microsoft explains it:

.NET Framework is the “full” or “traditional” flavor of .NET that’s distributed with Windows. Use this when you are building a desktop Windows or UWP app, or working with older ASP.NET 4.6+.

.NET Core is cross-platform .NET that runs on Windows, Mac, and Linux. Use this when you want to build console or web apps that can run on any platform, including inside Docker containers. This does not include UWP/desktop apps currently.

Xamarin is used for building mobile apps that can run on iOS, Android, or Windows Phone devices, usually runs on top of Mono, which is a version of .NET that was built for cross-platform support before Microsoft decided to officially go cross-platform with .NET Core. Like Xamarin, the Unity platform also runs on top of Mono.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *