Presented by .NET 5
On May 6, it was announced that the next release after .NET Core 3.0 would be .NET 5. This will 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 for Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly and other platforms.
We will introduce the new .NET API, the capabilities of the runtime environment, and the capabilities of the language 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. .NET Core 3.0 came close to the .NET Framework 4.8 by its capabilities, thanks to which 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 It turned out to be 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 of 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 executing environment, the same API, and language features, including new performance improvements , which are embedded into corefx almost daily.
Everything that you like about the .NET Core has been preserved:
Innovations:
.NET Core 3.0 will be available in September of this year, and .NET 5 - in November 2020. After that we are going to release the main versions of .NET once a year, every November:
We are missing the fourth version, because users may have 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 advantage of the opportunity and simplify the order of names. We believe that if only one .NET will be developed, we will not need an explanatory term “Core”. The short title is simpler, it says that the capabilities 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 an execution environment used as part of Xamarin.
CoreCLR is the execution environment used as part of the .NET Core. It was initially focused on supporting cloud applications, including the largest services at Microsoft, and today it is also used for desktop Windows applications, IoT, and machine learning.
The .NET Core and Mono runtimes have a lot in common (yet, 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. Now we are working to make CoreCLR and Mono pluggable replacements for each other. The process will be as simple as switching the assembly to choose between different options of the runtime environment.
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 simultaneously 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 JIT runtime with very high performance, while allowing developers to write code easily and quickly.
JIT compilers are well suited for long-running clouds and client-side 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 , this technique allows you to compile at high speeds, while at the same time creating a finely tuned version of the code if some methods are used frequently.
Our efforts to speed up the ASP.NET Core work, as reflected in the TechEmpower benchmark results , are a good example of JIT capabilities and are our contributions 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. To use the tools, it is often required to repeatedly compile and load code in the same process without restarting, and this should be done very quickly.
Developers using the .NET Core or .NET Framework primarily rely on JIT. So it should seem familiar to them.
A standard approach for most .NET 5 workloads is to use the CoreCLR runtime with JIT. Two important exceptions are iOS and Blazor client (WebAssembly), they require native pre-ahead (of-time) compilation.
As part of the Mono project, most efforts were focused on the mobile segment and game consoles. The main feature and result of this project is the AOT compiler for .NET, developed on the basis of the LLVM compiler. Mono's AOT compiler allows you to build .NET code into a single native executable code that can work on any machine, just like C ++ code. Precompiled (AOT) applications can run efficiently with limited resources (small places), and, if necessary, sacrifice performance for the sake of their launch.
The Blazor project is already using 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. The AOT of the first type is needed for iOS and some game consoles, 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 an AOT compiler that we use for Windows UWP applications. It refers to the first type of AOT-solutions. In this particular implementation, we have limited the .NET API and the features 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 hardware (appliance-like), for which a quick launch and / or low CPU consumption is required.
It is critical for us to continue to develop 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 on improving performance and reliability in CoreCLR, as well as on improving startup and reducing the file size of the Mono AOT compiler. It seems to us a good combination. Performance and reliability go hand in hand, as does startup speed with a decrease in file size.
It is advisable to invest different resources in improving some characteristics, but not in improving others.
Diagnostic capabilities should be the same for the entire .NET 5, this applies to both functionality and performance. It is also important to support the same processors and operating systems (with the exception of iOS and WebAssembly).
We will continue to optimize .NET 5 for all types of workloads and scripts for which it 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 Blazor client tasks.
All .NET 5 applications can be built using the .NET CLI , so that in all projects you will have a single command line toolkit.
C # will evolve with .NET 5. Developers who write .NET 5 applications will get 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 .NET Core) and Unity spoke about the various technical possibilities and directions for the development of architecture.
Now we move 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 the NuGet package compatibility rules remain the same? What load will the .NET 5 SDK support out of the box? How do you write code for a specific architecture? Do we need .NET Standard? We are currently working on all of this and will soon be able to share project documentation with you 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, 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 API and languages ​​for a wide range of applications, operating systems and processor architectures. You can easily change the configuration of the assembly, building applications as you wish - 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 for Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly and other platforms.
We will introduce the new .NET API, the capabilities of the runtime environment, and the capabilities of the language 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. .NET Core 3.0 came close to the .NET Framework 4.8 by its capabilities, thanks to which 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 It turned out to be 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 of 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 unified execution environment and framework that can be used everywhere, with the same runtime behavior and development experience.
- Extend the capabilities of .NET with best practices from the .NET Core, .NET Framework, Xamarin and Mono.
- Build a product from a single code base over 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 executing environment, the same API, and language features, including new performance improvements , which are embedded into corefx almost daily.
Everything that you like about the .NET Core has been preserved:
- Open source and focus on the GitHub community.
- Cross-platform implementation.
- Support for using specific platform-specific features, such as Windows Forms and WPF under Windows, as well as native bindings for each native platform from Xamarin.
- High performance.
- Side-by-side installation.
- Small size of project files (SDK-style).
- Command Line Interface (CLI) with extensive capabilities.
- Integration with Visual Studio, Visual Studio for Mac and Visual Studio Code.
Innovations:
- You will have more performance environment (more on this below).
- The ability to call Java code from .NET 5 will be available on all platforms.
- Calling Objective-C and Swift code from .NET 5 will be supported in several operating systems.
- CoreFX will be expanded to support static .NET compilation (ahead-of-time - AOT), to reduce resource consumption (footprints) and to support more operating systems.
.NET Core 3.0 will be available in September of this year, and .NET 5 - in November 2020. After that we are going to release the main versions of .NET once a year, every November:
We are missing the fourth version, because users may have 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 advantage of the opportunity and simplify the order of names. We believe that if only one .NET will be developed, we will not need an explanatory term “Core”. The short title is simpler, it says that the capabilities 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 an execution environment used as part of Xamarin.
CoreCLR is the execution environment used as part of the .NET Core. It was initially focused on supporting cloud applications, including the largest services at Microsoft, and today it is also used for desktop Windows applications, IoT, and machine learning.
The .NET Core and Mono runtimes have a lot in common (yet, 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. Now we are working to make CoreCLR and Mono pluggable replacements for each other. The process will be as simple as switching the assembly to choose between different options of the runtime environment.
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 simultaneously and at the same time separately.
High performance 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 JIT runtime with very high performance, while allowing developers to write code easily and quickly.
JIT compilers are well suited for long-running clouds and client-side 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 , this technique allows you to compile at high speeds, while at the same time creating a finely tuned version of the code if some methods are used frequently.
Our efforts to speed up the ASP.NET Core work, as reflected in the TechEmpower benchmark results , are a good example of JIT capabilities and are our contributions 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. To use the tools, it is often required to repeatedly compile and load code in the same process without restarting, and this should be done very quickly.
Developers using the .NET Core or .NET Framework primarily rely on JIT. So it should seem familiar to them.
A standard approach for most .NET 5 workloads is to use the CoreCLR runtime with JIT. Two important exceptions are iOS and Blazor client (WebAssembly), they require native pre-ahead (of-time) compilation.
Fast start-up, low CPU usage (footprint) and reduced memory consumption
As part of the Mono project, most efforts were focused on the mobile segment and game consoles. The main feature and result of this project is the AOT compiler for .NET, developed on the basis of the LLVM compiler. Mono's AOT compiler allows you to build .NET code into a single native executable code that can work on any machine, just like C ++ code. Precompiled (AOT) applications can run efficiently with limited resources (small places), and, if necessary, sacrifice performance for the sake of their launch.
The Blazor project is already using 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 where most of the code is AOT-compiled, but still allow using JIT or an interpreter for code patterns that are not friendly with AOT (for example, generics).
Mono AOT supports both types. The AOT of the first type is needed for iOS and some game consoles, 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 an AOT compiler that we use for Windows UWP applications. It refers to the first type of AOT-solutions. In this particular implementation, we have limited the .NET API and the features 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 hardware (appliance-like), for which a quick launch and / or low CPU consumption is required.
Basics and similar requirements
It is critical for us to continue to develop 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 on improving performance and reliability in CoreCLR, as well as on improving startup and reducing the file size of the Mono AOT compiler. It seems to us a good combination. Performance and reliability go hand in hand, as does startup speed with a decrease in file size.
It is advisable to invest different resources in improving some characteristics, but not in improving others.
Diagnostic capabilities should be the same for the entire .NET 5, this applies to both functionality and performance. It is also important to support the same processors and operating systems (with the exception of iOS and WebAssembly).
We will continue to optimize .NET 5 for all types of workloads and scripts for which it 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 Blazor client tasks.
All .NET 5 applications can be built using the .NET CLI , so that in all projects you will have a single command line toolkit.
C # will evolve with .NET 5. Developers who write .NET 5 applications will get access to the latest version of C # and its properties.
The birth of the project
As a technical team, we gathered in December 2018 in Boston to start this project. Leading architects from the .NET team (Mono / Xamarin and .NET Core) and Unity spoke about the various technical possibilities and directions for the development of architecture.
Now we move the project as a team. Since December, we have made great progress in several projects:
- A minimum level was determined, which defines the interaction between the runtime environment and the managed code layer, in order to make> 99% CoreFX common code.
- MonoVM can now use CoreFX and its class libraries.
- We drove all 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 the NuGet package compatibility rules remain the same? What load will the .NET 5 SDK support out of the box? How do you write code for a specific architecture? Do we need .NET Standard? We are currently working on all of this and will soon be able to share project documentation with you 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, 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 API and languages ​​for a wide range of applications, operating systems and processor architectures. You can easily change the configuration of the assembly, building applications as you wish - in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or from the command line.
Source: https://habr.com/ru/post/451136/
All Articles