.Net Framework, Core, and Standard
The distinction between these three concepts of .Net Framework, Core, and Standard, has long lay in a foggy corner of my brain saying “Danger! You do not understand the future of the primary technologies you use for everything!”. So I was glad when recently I was forced into understanding these things when I tried to create a NuGet package.
By far the best post I have found on this is from the .Net blog; Introducing .NET Standard.
A parable
So to explain, imagine you are making an Acme.Utilities library which you want to publish as a package. You build it in .Net Framework 4.5, and pack it up.
You go to test your package by starting a new Console App and importing it. You feel that Visual Studio 2017 is twisting your arm into making a Console App using .Net Core, so you go for that. Unsurprisingly, when you import your package, it complains that your app and the package are not compatible - this is because .Net Core 1.x and .Net Framework 4.5 are “not compatible” (please excuse this simplification for now).
So now you’re thinking, “Well, do I have to make a copy of my package code for every single framework I want to target?” - No!
What to do
To integrate with the .Net Framework and with .Net Core, your library project needs to target .Net Standard, check out this kickin’ table (source):
.NET Standard |
1.0 | 1.1 | 1.2 | 1.3 | 1.4 | 1.5 | 1.6 | 2.0 |
|---|---|---|---|---|---|---|---|---|
| .NET Core | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 1.0 | 2.0 |
| .NET Framework | 4.5 | 4.5 | 4.5.1 | 4.6 | 4.6.1 | 4.6.1 |
4.6.1 |
4.6.1 |
| Mono | 4.6 | 4.6 | 4.6 | 4.6 | 4.6 | 4.6 | 4.6 | 5.4 |
| Xamarin.iOS | 10.0 | 10.0 | 10.0 | 10.0 | 10.0 | 10.0 | 10.0 | 10.14 |
| Xamarin.Mac | 3.0 | 3.0 | 3.0 | 3.0 | 3.0 | 3.0 | 3.0 | 3.8 |
| Xamarin.Android | 7.0 | 7.0 | 7.0 | 7.0 | 7.0 | 7.0 | 7.0 | 8.0 |
| Universal Windows Platform | 10.0 | 10.0 | 10.0 | 10.0 | 10.0 | 10.0.16299 | 10.0.16299 | 10.0.16299 |
| Windows | 8.0 | 8.0 | 8.1 | |||||
| Windows Phone | 8.1 | 8.1 | 8.1 | |||||
| Windows Phone Silverlight | 8.0 |
When you are making a new class library project in VS, you may have noticed that you can pick between “Classic Windows Desktop”, “.Net Core”, and “.Net Standard”. I would say that if you want interoperability, then .Net Standard is always the one to go for.
You should aim to support the lowest .Net Standard version you possibly can, bearing in mind that some of the features you want won’t be available in lower Standard versions. For example, I make use of Path.DirectorySeparatorChar in one project, and this API is only available in Standard 1.3+
Conclusion
In essence, .Net Standard gives you a way of writing .Net code which can work in multiple different calling frameworks as long as they support the API standard which you wrote it to.