.NET Core 3.0 was released in September 2019, followed by the LTS (Long-Term Support) version .NET Core 3.1 in December. Microsoft’s messaging was clear at that time:
- .NET Core 3.1 is the recommended version of .NET for all new applications.
- Existing .NET framework applications do not need to be upgraded to .NET Core. The .NET framework will remain supported as an integral part of Windows.
- If you want to port your existing .NET framework applications to .NET Core, there is no reason to wait any longer. Porting old application models to .NET Core is complete. The application models that have not yet been ported, will not be ported in the future.
Since then, Microsoft has been working hard on the next version – .NET 5. New preview versions have been regularly available for download and testing since March 2020. The planned release in November 2020 is just around the corner.
.NET 5 – Original plan
When .NET 5.0 Preview 1 was released in March 2020, Microsoft revealed its plans for this version.
The plan was to unify all .NET runtimes into a single .NET platform with unified base class libraries (BCL) for all application models: ASP.NET Core, Windows Forms, WPF, UWP, Xamarin, Blazor.
This would make .NET a unified platform for all types of applications. A single native device project would support Windows desktop, Android, and iOS development. A single Blazor project would support applications running in a browser, on a mobile device, or in a desktop application.
Performance would continue to be the focus: faster algorithms, improvements to the RyuJIT (just-in-time) compiler and garbage collector, smaller executables for faster startup times, and so on.
.NET 5 updates at Microsoft Build
In May 2020, at the Microsoft Build conference, Microsoft unveiled changes to the original plan for .NET 5.
Due to the ongoing global health pandemic, the unification of all the .NET runtimes was postponed to .NET 6 which is planned for release in November 2021. .NET 5 would still be released in November 2020 but would focus on (performance) improvements of .NET Core 3.1.
Editorial Note: You may want to read Microsoft Build 2020 for Developers – Recap.
Figure 1: .NET runtimes before the unification in .NET 6
New target frameworks in .NET 5
In preparation for the runtime unification in .NET 6, .NET 5 will already ship with an updated approach to target framework versions. These are specified with the so-called Target Framework Monikers (TFMs), i.e. short code-names that identify the set of APIs a project is targeting. You can see them used in any new SDK-style .csproj project file:
Currently, every .NET runtime has its own set of TFMs, for example, netcoreapp3.1 for .NET Core 3.1 and net48 for the .NET framework 4.8. The .NET Standard has its own set of TFMs, e.g. netstandard2.1 for .NET Standard 2.1. The latter must be used for libraries that are shared between multiple runtimes, e.g. .NET Core and Xamarin.
With .NET 5, net5.0 will remain as the only TFM. The net prefix instead of netcoreapp will be used as this will be the only version of .NET that is still under development. The renaming is also consistent with the renaming of .NET Core 3.1 to .NET 5.
The net5.0 TFM will also be the successor of the netstandard TFMs. Since only a single .NET runtime will remain, there is no need for new versions of the .NET Standard that define a subset of APIs available across different runtimes. The full set of .NET 5 APIs will be available for all application models, including Xamarin, once it runs on top of this new unified runtime as is currently planned for .NET 6.
This means that regular .NET Core libraries will be consumed by all application models.
Application models that target a specific operating system will be able to provide additional APIs in addition to the full .NET 5 API set. Their TFMs will consist of the prefix that defines the core .NET set of APIs and a postfix indicating the operating system the additional APIs target, for example:
- net5.0-windows will provide additional APIs for the Windows operating system, such as WinForms and WPF.
- net5.0-ios will provide additional APIs specifically for the iOS operating system, which are currently available as part of Xamarin.
Not all supported operating systems will need their own TFMs. If no platform-specific APIs are supported (current examples are Linux and WebAssembly), the .NET runtime prefix is used (e.g. net5.0).
Figure 2: .NET runtimes after the unification in .NET 6
Single file applications
In .NET 5, a new publish type will be introduced that will output the complete application and all its dependencies (including the .NET runtime) as a single file to be distributed. This feature will be fully supported with the x64 architecture on Windows, macOS, and Linux. It will work with ARM32 and ARM64, but will not be actively validated and supported.
On Windows, the single-file goal will not be fully achieved. The executable will still need four additional files at runtime. There will be an option to include these files in a single distributable file, but they will be extracted as separate files the first time the application starts.
Further development and refinement of the feature are planned for future releases of .NET.
Performance improvements in .NET 5
A lot of work is being done to achieve better consistent performance. It is measured using the P95 latency metric, which is the 95th percentile of the latency value, meaning that 95% of requests have a latency below this value. The RyuJIT compiler and the garbage collector have the greatest impact on this metric:
- The tiered compilation is an approach that enables faster initial compilation by not performing any optimizations the first time a method is compiled. Methods that are used frequently can then be recompiled with higher quality by applying additional optimizations. In .NET 5, such methods are now better identified by call counting. Methods with loops receive special treatment by being optimized immediately because of the high impact they could have even if they are called only once.
- RyuJIT contains many other code generation improvements. A special category of these improvements is hardware intrinsics, i.e. support for targeting specific instruction sets of certain processors (e.g. SSE and AVX).
- Garbage collector enhancements help reduce application pause times when garbage collection is running and optimize garbage collector’s scanning of managed memory for candidates to undergo garbage collection.
In addition to that, many APIs are also being optimized for better performance, most notably:
- HTTP 1.1 and HTTP/2 implementation,
- regular expressions, and
- string operations.
Several changes are specifically aimed at improving performance in container workload scenarios:
- All around better .NET performance in container environments.
- Reduction of the size of published images and a bigger selection of available images.
- Support for orchestration APIs such as OpenTelemetry to make it easier to work with .NET in such environments.
.NET Core 3.1 was already available for Linux ARM64 and had full functional parity with the x64 version. In terms of performance, however, it was not on parity. To change that in .NET 5, several important investments were made in this area:
- JIT (just-in-time) compiler optimizations for ARM64.
- Support for ARM64 hardware intrinsics, i.e. specialized instruction sets.
- Tailored performance-critical algorithms for ARM64.
There was no native support for Windows ARM64 in .NET Core 3.1 which meant that all .NET Core and .NET framework applications could only run in x86 emulation mode on these devices. In .NET 5, full native support for Windows ARM64 (on devices such as Surface Pro X) will be provided, both for development and for running applications.
Not many changes are planned for ASP.NET Core.
Kestrel will provide performance improvements for HTTP/2 thanks to newly supported HPack header compression. It will also support binding to new endpoints on configuration changes without the need to restart the application.
SignalR Hub filters will allow code execution before or after the Hub methods. That is how middleware works for HTTP requests.
Although Blazor WebAssembly will continue to run on the Mono runtime, it will switch to .NET runtime libraries which will give it higher compatibility until the common .NET runtime will finally be used in .NET 6. Performance should also be improved compared to Blazor WebAssembly 3.2.
Entity Framework Core
Entity Framework Core 5.0 is technically not part of .NET 5, although it is planned to be released in the same timeframe. The library is distributed in the form of standalone NuGet packages that are planned to be fully compatible with .NET Standard 2.1, which means that they will also be compatible with .NET Core 3.1. This is still a change from Entity Framework Core 3.0 which is .NET Standard 2.0 compatible and even works with the .NET framework.
Most improvements in Entity Framework Core 5.0 belong in one of the following two categories:
- SQL query generation works in more cases and generates better queries.
- More options are available when describing the database model in code.
Language Updates in .NET 5
.NET 5 will also be accompanied by some changes to the supported programming languages:
- C# 9 will bring several new language features focused on improving the experience of working with immutable data structures and enabling terser code in general. The most notable changes are the introduction of the long awaited record types and further improvements to pattern matching.
- F# 5 focuses on improvements in interactive and analytical programming to make the Jupyter notebooks experience even better.
- Visual Basic will not develop further as a language. To facilitate porting of Visual Basic based .NET framework applications, more project types will work with Visual Basic in .NET 5: Windows Forms, WPF, Worker Service and ASP.NET Core Web API in addition to Class Library and Console applications which are already supported in .NET Core 3.1. No new features of .NET Core that would require a language change will be supported in Visual Basic.
C# Source Generators
Although not necessarily a language enhancement or part of .NET 5, C# source generators are closely related to both. This Roslyn compiler feature adds meta-programming support to C#. Like analyzers, source generators will have access to the application code but will be able to generate additional C# source files that will be included in the final compilation. In many cases, this technique will be able to replace Reflection calls at runtime and IL weaving, for example, to automatically implement the INotifyPropertyChanged interface.
Current state of .NET 5
.NET 5.0 Preview 8 released last week is planned to be the final preview version. At this point, .NET 5 should be feature complete.
So if you are planning to get started with .NET 5, now is a good time!
Before the final release in November 2020, two more release candidates (RCs) are planned to be released. Both will have the “go-live” license, which means they will be fully supported for use in production.
As an additional assurance of .NET 5 quality, Microsoft has been running 50% of the load to its .NET website on the latest .NET 5 release since .NET 5.0 Preview 1. This is another way for them to get realistic performance data right from the start. When you visit the website, you can see the runtime it was served by in its footer. If you refresh it a few times, you can be sure that sooner or later you will hit the .NET 5 runtime. See Figure 3.
Figure 3: .NET website running on .NET 5
If you want to give .NET 5 a try, you can download the latest .NET 5 release from the .NET website. You can use it with the Visual Studio 2019 Preview, with Visual Studio for Mac or with the latest version of the C# extension for Visual Studio Code.
Editorial: For those interested, you can view the .NET 5 release notes on Github.
Due to the delays caused by the on-going pandemic, .NET 5 will not yet bring a unification of all the .NET runtimes, as originally planned. However it will still bring a lot of improvements, especially in terms of performance.
If you’re interested in upgrading your .NET Core 3.1 projects to .NET 5 although it will only be a Current release and not an LTS (Long-Term Support) one like .NET Core 3.1 is, you can already start with initial testing. You don’t even have to wait for the final release in November 2020 to go into production, as the release candidates will already be fully supported with their “go-live” license.
If you still have projects that don’t use the latest version of .NET Core, you can start upgrading them to .NET Core 3.1 already. That’s the best way to prepare for .NET 5 and future releases.
This article was technically reviewed by Daniel Jimenez Garcia.
This article has been editorially reviewed by Suprotim Agarwal.
C# and .NET have been around for a very long time, but their constant growth means there’s always more to learn.
We at DotNetCurry are very excited to announce The Absolutely Awesome Book on C# and .NET. This is a 500 pages concise technical eBook available in PDF, ePub (iPad), and Mobi (Kindle).
Organized around concepts, this Book aims to provide a concise, yet solid foundation in C# and .NET, covering C# 6.0, C# 7.0 and .NET Core, with chapters on the latest .NET Core 3.0, .NET Standard and C# 8.0 (final release) too. Use these concepts to deepen your existing knowledge of C# and .NET, to have a solid grasp of the latest in C# and .NET OR to crack your next .NET Interview.
Click here to Explore the Table of Contents or Download Sample Chapters!