Demystifying .NET Standard
When .NET Framework was released 16 years ago, it served as a general application development platform for Windows desktop and Web applications.Shortly after, the .NET Compact Framework was released as a subset of the .NET Framework that fit the footprint of smaller devices, specifically Windows Mobile. The idea behind that was to separate code base from the .NET Framework and it included the entire vertical: a runtime, a framework, and an application model on top. Ever since that, this subsetting was repeated many times with: Silverlight, Windows Phone and Windows Store. This lead to fragmentation because the .NET Platform isn’t a single entity but a set of platforms, owned by different teams, and maintained independently.
Figure 1 source Microsoft official site
What is the problem with fragmentation? If you target a single vertical, you’re provided with an API set that is optimized for that vertical. The problem arises when you want to target the horizontal, that is multiple verticals. In these days, it is common to have applications that span devices: there is a back end that runs on the web server, there is often a front end that uses the Windows desktop, and a set of mobile applications that are exposed to the consumer, available for multiple devices.
For developers, sharing a library code or component between these platforms requires to re-implement and build it for specific platform though they were providing same feature.
To solve this problem, Microsoftintroduced a new way of compiling libraries calledPortable class libraries. This allowed the developers to build portable libraries which exposed only those Base Class Libraries (BCL) that are common between the selected platforms.
Figure 2 Visual Studio tooling for Portable Class Libraries
Though the portable libraries allowed code sharing between multiple platforms, it still had disadvantages like, adding a new platform support requires re-compiling against the new set of target platforms and removing the API references that are not part of new intersection of base class libraries.
Where does .NET standard fit in?
There are currently three major frameworks of .NET, which means that you have tomaster three different base class libraries in order to write code that work across them all.
Figure 3 Most popular flavors of .NET
To solve this difficulties with having multiple class libraries,.NETStandard was introduced. It is a specification that represents a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.
“The .NET Standard is a set of APIs that are implemented by the Base Class Library of a .NET implementation. More formally, it’s a specification of .NET APIs that make up a uniform set of contracts that you compile your code against. These contracts are implemented in each .NET implementation. This enables portability across different .NET implementations, effectively allowing your code to run everywhere.” – Microsoft official site
If you’re familiar with .NET Framework, then you should be familiar with the BCL. The BCL is the set of fundamental APIs that are independent of UI frameworks and application models. It includes the primitive types, file I/O, networking, reflection, serialization, XML and more.
Figure 4 Microsoft official site
.NET Standard is not something that can be installed – it is a formal specification of APIs that can be used.A good analogy is HTML and browsers: Think of the HTML specification as the .NET Standard and the different browsers as the .NET implementations, such as .NET Framework, .NET Core and Xamarin..NET Standard is an evolution of Portable Class Libraries and it replaces them as a tool for building .NET libraries that work anywhere.
.NET Standard versioning
The .NET Standard is versioned similar to framework versioning. The various .NET implementations target specific version of .NET Standard. Each .NET implementation version adverts the highest .NET Standard version it supports, it means that also supports previous versions.
The following table lists all versions of .NET Standard and platforms supported:
Figure 5 Supported versions
There are two primary versioning rules:
- Additive: Higher versions incorporate all APIs from previous versions.
- Immutable: Once shipped, .NET Standard versions are frozen. If the new APIs should be made available everywhere, new version of .NET Standard is created.
How to create .NET Standard library?
Visual Studio 2017 has a new project template called .NET Standard to create .NET Standard libraries.
Figure 6 Screenshot Visual Studio .NET Standard Class Library
Once the class library is created, we can check what version of the .NET Standard is targeted. Right-click on the library project in the Solution Explorer windows, then select Properties. The Target Framework text box shows what .NET Framework we are targeting.
Figure 7 Screenshot from Visual Studio
We can make our class library available by publishing it as a NuGet package. If we select the Package tab, we can configure package properties:
Figure 8 Screenshot from Visual Studio – Package configuration
Save the changes and set the configuration to Release. Right click the project in Solution Explorer and select the Pack command. Visual Studio will build the project and create the .nupkg file.
Figure 9 Screenshot from Visual Studio 2017
Microsoft created .NET Standard so that sharing and re-using code between multiple .NET platforms becomes much easier.For developers, this means that they have to master only one base class library. Libraries targeting .NET Standard will be able to run on all .NET platforms. When you are buildinga modern application, you should consider using this specification.