Hello .NET 5 | Do We Need a New .NET?

5 min readJul 3, 2020

The next evolution of .NET is just around the corner and there are many reasons to get excited. In this article we are going look at why this version is an important next step and how it is set to unify the .NET platform after nearly 20 years.

Where are we now?

Since the first release in 2002 .NET has had to constantly adapt to support different technologies. The platform has split into several different versions causing fragmentation. Just a few examples are:

Compact Framework for early mobile / embedded devices 📟
Silverlight for cross-browser development 🌐
Windows Phone for Windows Phone 8 📱

These alternative versions forked from the original .NET Framework but have no standardisation across developer APIs. This meant it was difficult or even impossible to create a single common .NET library that could be shared across platforms.

Portable Class Libraries

Portable Class Libraries solved some of these fragmentation issues in 2011. These libraries only have access to a subset of the available .NET APIs but can be referenced by several different .NET implementations. Each implementation then guarantees which set of APIs it supports. The ‘Target Platforms’ a project uses will therefore limit which APIs are available to it.

There are several reasons why Portable Class Libraries are not the solution to cross-platform development though. The various .NET implementations are managed and released independently so there is not always a perfect alignment of which portable APIs are supported and some implementations may lag behind others. Portable Class Libraries also only target a small subset of .NET implementations.

Along came .NET Core…

In 2016 .NET Core was the change we needed to simplify cross-platform development. It re-implemented .NET as a modular, open-source project, built to support a wide range of platforms from the get-go.

On the downside, the arrival of .NET Core meant there were now at least three major .NET implementations:

.NET Framework
.NET Core
Xamarin

Each implementation has its own Base Class Library (BCL), which continues to restrict how easily common code can be shared across all platforms.

The BCL provides the most foundational types and utility functionality and is the base of all other .NET class libraries. They aim to provide very general implementations without any bias to any workload. [Microsoft]

…and then .NET Standard

.NET Standard quickly followed a year later, providing a common Base Class Library across the .NET landscape and replacing the need for Portable Class Libraries. .NET Standard is a specification that defines which APIs all .NET platforms must implement. A library targeting .NET Standard will therefore be guaranteed to work across all .NET platforms of a particular version.

When compiling a library, .NET Standard is represented by a single ‘reference assembly’ which simply defines the APIs the compiler sees rather than containing any actual implementation. At runtime the .NET platform type forwards each API to its implementation.

Although we now have a simple way to create cross-platform and .NET agnostic libraries, there is still fragmentation. A matrix of choice awaits developers when picking which platform to target:

.NET Standard Version Matrix (Source: github)

Side Note: Don’t forget Shared Projects

It’s also worth noting Shared Projects as another useful innovation that helps share code across different project types. These allow you to create a virtual project with common code shared across multiple projects. They cannot be compiled themselves, so the code can’t be distributed as a library, but they are instead compiled by the referencing project.

Hello .NET 5

It looks like .NET 5 is the solution to our fragmentation problem. It is a unified, cross-platform .NET with a single runtime and framework. This new release replaces .NET Core, Framework and Standard.

One can think of .NET 5.0 as .NET Standard but with an implementation (.NET Core). [Microsoft]

This is great news for developers, as it simplifies the decision process when creating new applications and libraries. A .NET 5 project can be compiled as a standalone executable or a library to be reused across platforms and .NET implementations.

Target Framework

Specifying a project’s target framework has been simplified in .NET 5. A compacted Target Framework Moniker (TFM) is used in your project properties as follows:

<PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
</PropertyGroup>

The netcoreapp and netstandard TFMs are combined into net5.0

OS Specific Functionality

By default .NET 5 will not include Operating System-specific APIs. However, with any cross-platform framework there will be times when specialist functionality is required. To expose the OS APIs, the TFM can be extended to include the OS, and optionally the OS Version.

To target Windows-specific APIs the TFM net5.0-windows is provided. This will include WinForms and WPF in your project.

Of course .NET is no longer just about Windows, so the following OS variations are available and compatible with existing Xamarin variants:

net5.0-android
net5.0-ios
net5.0-macos
net5.0-tvos
net5.0-watchos

These new TFMs make it really intuitive to understand library compatibility and replace the requirement for confusing version matrices as seen above.

How To Prepare

The best advice for libraries, regardless of .NET 5, is to target the earliest version of .NET Standard your project requirements allows (i.e. the earliest version that provides the APIs you need). The lower the version, the more platforms implement it .All versions of .NET Standard will continue to work forever.

Any new applications should target .NET Core 3.1 and can then easily upgrade to .NET 5 once fully released in November.

Existing .NET Framework projects can start being moved across to .NET Standard or .NET Core now. Since .NET Core 3.0 no more APIs are being ported across from .NET Framework, so there is no need to wait. Also, no new major versions of .NET Framework will be released. It will continue to be supported, however. This essentially means no new functionality, but fixes and security patches will continue.

Note: Framework Projects need to be properly ported, rather than just updated, to target another implementation.