Introduced by .NET 5
- Transfer
On May 6, it was announced that the next release after .NET Core 3.0 would be .NET 5. This would be the next big release in the .NET family.
In the future there will be only one .NET, and you can use it for development under Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly and other platforms.
We will introduce new .NET APIs, runtime capabilities, and language features as part of .NET 5.
Since the launch of the .NET Core project, we have added about 50,000 .NET Framework APIs to the platform. By its capabilities, .NET Core 3.0 closely approached the .NET Framework 4.8, thanks to it Windows Forms, WPF and Entity Framework 6 became available. .NET 5 took over the baton, it was based on .NET Core and all the best from the Mono project, resulting in a single platform that can be used for all of your modern .NET code.
We intend to release .NET 5 in November 2020, and the first preview version will be available in the first half of 2020. The platform will be available along with future updates to Visual Studio 2019, Visual Studio for Mac, and Visual Studio Code.
.NET 5 is the next step in .NET Core. The project aims to improve .NET in several key aspects:
This new project and direction will completely change the situation with .NET. Thanks to .NET 5, your code and project files will look consistent, regardless of the type of application you are creating. From each application, you will have access to the same runtime, the same API and language features, including new performance improvements that are implemented in corefx almost daily.
Everything you like about .NET Core has been preserved:
Innovations:
.NET Core 3.0 will be available in September this year, and .NET 5 will be available in November 2020. After that, we are going to release the main versions of .NET once a year, every November:
We skip the fourth version, because users may experience confusion with the .NET Framework, which has long been released in version 4.x. In addition, we wanted to make clear that .NET 5 is the future of the .NET platform.
We also decided to take this opportunity and simplify the order of names. We believe that if only one .NET develops, then we will not need the explanatory term “Core”. The short name is simpler, it means that the features and behavior of .NET 5 are unified. If you want, you can continue to use the name. NET Core.
Mono is the original cross-platform implementation of .NET. It began as an open-source alternative to the .NET Framework, and later, with the growing popularity of iOS and Android devices, we reoriented it to the mobile segment. Mono is a runtime environment used as part of Xamarin.
CoreCLR is a runtime environment used as part of .NET Core. Initially focused on supporting cloud applications, including the largest services at Microsoft, today it is also used for Windows desktop applications, IoT, and machine learning.
The .NET Core and Mono runtimes have a lot in common (nevertheless, both of them are .NET runtimes), but each has its own unique capabilities. Therefore, it makes sense to give you the opportunity to choose the experience of use that you need. We are currently working to make CoreCLR and Mono plug-in replacements for each other. The process will be as simple as switching the assembly to choose between different runtime options.
In the following chapters, I will describe our key plans for .NET 5. They will help you understand how we are going to develop two runtimes at the same time and at the same time separately.
From the very beginning, .NET relied on a JIT compiler to convert Intermediate Language code into optimized machine code. We have created the industry's best runtime environment with JIT, with very high performance, while allowing developers to write code quickly and easily.
JIT compilers are well suited for long-running clouds and client scripts. They are able to generate code that takes into account the features of the hardware configuration, including specific processor instructions. JIT can also generate methods at runtime again , this technique allows you to compile at high speed, while at the same time creating a finely tuned version of the code if some methods are used frequently.
Our efforts to accelerate the performance of ASP.NET Core, which were reflected in the results of the TechEmpower benchmarks , are a good example of the capabilities of JIT and are our contribution to CoreCLR. We tried to prepare .NET Core for the use of containers , this demonstrates the ability of the runtime environment to dynamically adapt to limited environments.
Developer tools are another area in which JIT has proven itself, for example, dotnet watch or “edit and continue” mode. Tools often require compiling and downloading code in the same process many times without restarting, and you need to do this very quickly.
Developers using the .NET Core or the .NET Framework primarily rely on JIT. So it should seem familiar to them.
The standard approach for most .NET 5 workloads is to use the CoreCLR runtime with JIT. Two important exceptions are iOS and client Blazor (WebAssembly), they require native preliminary (ahead-of-time) compilation.
As part of the Mono project, most of the efforts were aimed at the mobile segment and game consoles. The main opportunity and result of this project is the AOT compiler for .NET, developed based on the LLVM compiler . The Mono AOT compiler allows you to compile .NET code into a single, native executable code that can run on any machine, just like C ++ code. Pre-compiled (AOT) applications can be executed efficiently with limited resources (small places) and, if necessary, sacrifice performance for their launch.
The Blazor project already uses Mono AOT and is one of the first to switch to .NET 5. We use it as one of the ways to prove our plans.
There are two types of AOT solutions:
Mono AOT supports both types. AOT of the first type is needed for iOS and some game consoles, this is mainly due to security requirements. Solutions of the second type are more preferable because they have all the advantages of AOT without its disadvantages.
The .NET Native is the AOT compiler we use for Windows UWP applications. It belongs to the first type of AOT solutions. In this particular implementation, we have limited the .NET API and the options available to you. This helped us understand that AOT solutions should cover the full range of .NET APIs and patterns.
AOT compilation will remain necessary for iOS, WebAssembly and some game consoles. We will make it optional for applications that are embedded in appliances (appliance-like), which require a quick start and / or low CPU consumption.
It is critical for us to continue to evolve as a platform with controls for launch, performance, memory consumption, reliability and diagnostics. At the same time, it is advisable to focus our efforts. We will work more to improve performance and reliability in CoreCLR, as well as to improve the launch and file size reduction of the Mono AOT compiler. It seems to us a good combination. Performance and reliability go hand in hand, as does startup speed with reduced file sizes.
It is advisable to invest different resources in improving some characteristics, but not in improving others.
Diagnostic capabilities should be the same throughout .NET 5, this applies to both functionality and performance. It is also important to support the same processors and OS (with the exception of iOS and WebAssembly).
We will continue to optimize .NET 5 for all kinds of workloads and scripts for which this makes sense. The greatest emphasis will be placed on optimizations, especially in cases where different loads impose similar requirements.
All .NET 5 applications will use the CoreFX framework . We will make sure that CoreFX works well where it is not used today, mainly Xamarin client Blazor tasks.
All .NET 5 applications can be built using the .NET CLIso that in all projects you will have a single toolkit based on the command line.
C # will evolve with .NET 5. Developers writing .NET 5 applications will have access to the latest version of C # and its properties.
As a technical team, we gathered in December 2018 in Boston to start this project. Leading architects from the .NET team (Mono / Xamarin and the .NET Core) and Unity talked about various technical capabilities and the direction of development of the architecture.
Now we are moving the project as a team. Since December, we have made great progress in several projects:
The pursuit of a single .NET implementation raises important questions. What will be the final framework? Will NuGet Package Compatibility Rules Remain? What load will the .NET 5 SDK support out of the box? How to write code for a specific architecture? Do we need .NET Standard? Now we are working on all this and will soon be able to share with you the project documentation so that you can read it and give feedback.
The .NET 5 project is an important and inspiring new direction for .NET. You will see that .NET will become easier, but at the same time it will be used more widely, it will gain more opportunities. All new development features will become part of .NET 5, including new versions of C #.
We have a bright future ahead in which you can use the same .NET APIs and languages for a wide range of applications, operating systems and processor architectures. You can easily change the build configuration by assembling applications as you like - in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or from the command line.
In the future there will be only one .NET, and you can use it for development under Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly and other platforms.
We will introduce new .NET APIs, runtime capabilities, and language features as part of .NET 5.
Since the launch of the .NET Core project, we have added about 50,000 .NET Framework APIs to the platform. By its capabilities, .NET Core 3.0 closely approached the .NET Framework 4.8, thanks to it Windows Forms, WPF and Entity Framework 6 became available. .NET 5 took over the baton, it was based on .NET Core and all the best from the Mono project, resulting in a single platform that can be used for all of your modern .NET code.
We intend to release .NET 5 in November 2020, and the first preview version will be available in the first half of 2020. The platform will be available along with future updates to Visual Studio 2019, Visual Studio for Mac, and Visual Studio Code.
.NET 5 = .NET Core vNext
.NET 5 is the next step in .NET Core. The project aims to improve .NET in several key aspects:
- Create a single runtime and framework that can be used everywhere, with the same runtime behavior and development experience.
- Extend .NET with the best of .NET Core, .NET Framework, Xamarin and Mono.
- Build a product from a single code base on which developers (from Microsoft and the community) can work together and expand it, which will improve all possible scenarios.
This new project and direction will completely change the situation with .NET. Thanks to .NET 5, your code and project files will look consistent, regardless of the type of application you are creating. From each application, you will have access to the same runtime, the same API and language features, including new performance improvements that are implemented in corefx almost daily.
Everything you like about .NET Core has been preserved:
- Open source and community focus on GitHub.
- Cross-platform implementation.
- Support for the use of specific platform-specific features, such as Windows Forms and WPF for Windows, as well as native bindings for each native platform from Xamarin.
- High performance.
- Side-by-side installation.
- Small project file size (SDK style).
- Powerful command line interface (CLI).
- Integration with Visual Studio, Visual Studio for Mac, and Visual Studio Code.
Innovations:
- You will have more runtime capabilities (more on this below).
- The ability to call Java code from .NET 5 will be available on all platforms.
- Objective-C and Swift code invocation from .NET 5 will be supported on several operating systems.
- CoreFX will be expanded to support static .NET (ahead-of-time - AOT) compilation, to reduce footprints and support more operating systems.
.NET Core 3.0 will be available in September this year, and .NET 5 will be available in November 2020. After that, we are going to release the main versions of .NET once a year, every November:
We skip the fourth version, because users may experience confusion with the .NET Framework, which has long been released in version 4.x. In addition, we wanted to make clear that .NET 5 is the future of the .NET platform.
We also decided to take this opportunity and simplify the order of names. We believe that if only one .NET develops, then we will not need the explanatory term “Core”. The short name is simpler, it means that the features and behavior of .NET 5 are unified. If you want, you can continue to use the name. NET Core.
Runtime environments
Mono is the original cross-platform implementation of .NET. It began as an open-source alternative to the .NET Framework, and later, with the growing popularity of iOS and Android devices, we reoriented it to the mobile segment. Mono is a runtime environment used as part of Xamarin.
CoreCLR is a runtime environment used as part of .NET Core. Initially focused on supporting cloud applications, including the largest services at Microsoft, today it is also used for Windows desktop applications, IoT, and machine learning.
The .NET Core and Mono runtimes have a lot in common (nevertheless, both of them are .NET runtimes), but each has its own unique capabilities. Therefore, it makes sense to give you the opportunity to choose the experience of use that you need. We are currently working to make CoreCLR and Mono plug-in replacements for each other. The process will be as simple as switching the assembly to choose between different runtime options.
In the following chapters, I will describe our key plans for .NET 5. They will help you understand how we are going to develop two runtimes at the same time and at the same time separately.
High productivity and productivity
From the very beginning, .NET relied on a JIT compiler to convert Intermediate Language code into optimized machine code. We have created the industry's best runtime environment with JIT, with very high performance, while allowing developers to write code quickly and easily.
JIT compilers are well suited for long-running clouds and client scripts. They are able to generate code that takes into account the features of the hardware configuration, including specific processor instructions. JIT can also generate methods at runtime again , this technique allows you to compile at high speed, while at the same time creating a finely tuned version of the code if some methods are used frequently.
Our efforts to accelerate the performance of ASP.NET Core, which were reflected in the results of the TechEmpower benchmarks , are a good example of the capabilities of JIT and are our contribution to CoreCLR. We tried to prepare .NET Core for the use of containers , this demonstrates the ability of the runtime environment to dynamically adapt to limited environments.
Developer tools are another area in which JIT has proven itself, for example, dotnet watch or “edit and continue” mode. Tools often require compiling and downloading code in the same process many times without restarting, and you need to do this very quickly.
Developers using the .NET Core or the .NET Framework primarily rely on JIT. So it should seem familiar to them.
The standard approach for most .NET 5 workloads is to use the CoreCLR runtime with JIT. Two important exceptions are iOS and client Blazor (WebAssembly), they require native preliminary (ahead-of-time) compilation.
Fast startup, low footprint and reduced memory footprint
As part of the Mono project, most of the efforts were aimed at the mobile segment and game consoles. The main opportunity and result of this project is the AOT compiler for .NET, developed based on the LLVM compiler . The Mono AOT compiler allows you to compile .NET code into a single, native executable code that can run on any machine, just like C ++ code. Pre-compiled (AOT) applications can be executed efficiently with limited resources (small places) and, if necessary, sacrifice performance for their launch.
The Blazor project already uses Mono AOT and is one of the first to switch to .NET 5. We use it as one of the ways to prove our plans.
There are two types of AOT solutions:
- Requiring full AOT compilation.
- Solutions, most of the code of which is AOT-compiled, but still allowing you to use a JIT or interpreter for such code patterns that are not friends with AOT (for example, generics).
Mono AOT supports both types. AOT of the first type is needed for iOS and some game consoles, this is mainly due to security requirements. Solutions of the second type are more preferable because they have all the advantages of AOT without its disadvantages.
The .NET Native is the AOT compiler we use for Windows UWP applications. It belongs to the first type of AOT solutions. In this particular implementation, we have limited the .NET API and the options available to you. This helped us understand that AOT solutions should cover the full range of .NET APIs and patterns.
AOT compilation will remain necessary for iOS, WebAssembly and some game consoles. We will make it optional for applications that are embedded in appliances (appliance-like), which require a quick start and / or low CPU consumption.
Basics and related requirements
It is critical for us to continue to evolve as a platform with controls for launch, performance, memory consumption, reliability and diagnostics. At the same time, it is advisable to focus our efforts. We will work more to improve performance and reliability in CoreCLR, as well as to improve the launch and file size reduction of the Mono AOT compiler. It seems to us a good combination. Performance and reliability go hand in hand, as does startup speed with reduced file sizes.
It is advisable to invest different resources in improving some characteristics, but not in improving others.
Diagnostic capabilities should be the same throughout .NET 5, this applies to both functionality and performance. It is also important to support the same processors and OS (with the exception of iOS and WebAssembly).
We will continue to optimize .NET 5 for all kinds of workloads and scripts for which this makes sense. The greatest emphasis will be placed on optimizations, especially in cases where different loads impose similar requirements.
All .NET 5 applications will use the CoreFX framework . We will make sure that CoreFX works well where it is not used today, mainly Xamarin client Blazor tasks.
All .NET 5 applications can be built using the .NET CLIso that in all projects you will have a single toolkit based on the command line.
C # will evolve with .NET 5. Developers writing .NET 5 applications will have access to the latest version of C # and its properties.
Project birth
As a technical team, we gathered in December 2018 in Boston to start this project. Leading architects from the .NET team (Mono / Xamarin and the .NET Core) and Unity talked about various technical capabilities and the direction of development of the architecture.
Now we are moving the project as a team. Since December, we have made great progress in several projects:
- We determined the minimum level that determines the interaction of the runtime and the managed code layer in order to make> 99% CoreFX a common code.
- MonoVM can now use CoreFX and its class libraries.
- We ran all the CoreFX tests on MonoVM using its implementation.
- Launched ASP.NET Core 3.0 applications on MonoVM.
- Launched MonoDevelop and Visual Studio for Mac on CoreCLR.
The pursuit of a single .NET implementation raises important questions. What will be the final framework? Will NuGet Package Compatibility Rules Remain? What load will the .NET 5 SDK support out of the box? How to write code for a specific architecture? Do we need .NET Standard? Now we are working on all this and will soon be able to share with you the project documentation so that you can read it and give feedback.
Conclusion
The .NET 5 project is an important and inspiring new direction for .NET. You will see that .NET will become easier, but at the same time it will be used more widely, it will gain more opportunities. All new development features will become part of .NET 5, including new versions of C #.
We have a bright future ahead in which you can use the same .NET APIs and languages for a wide range of applications, operating systems and processor architectures. You can easily change the build configuration by assembling applications as you like - in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or from the command line.