[Translation] Introducing .NET 5

[Translation] Introducing .NET 5


On May 6, it was announced that the following after . NET Core 3.0 the release will 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 under Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly and other platforms.

We will introduce the new .NET API, the capabilities of the runtime, 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 using the .NET Framework 4.8 is complemented by the majority of missing features, 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 project Mono , 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 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 single runtime and framework that can be used everywhere, with the same runtime behavior and development experience.
  • Extend the capabilities of .NET with best practices from .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 executing environment, the same API, and language features, including new ones from performance improvements that are embedded in corefx almost daily.

Everything that you like about .NET Core has survived:

  • 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).
  • A rich command line interface (CLI).
  • Integration with Visual Studio, Visual Studio for Mac, and Visual Studio Code.

Innovations:

  • You will have more features of the runtime environment (more on this below).
  • The ability to call Java code from .NET 5 will be available on all platforms.
  • Objective-C and Swift code calls from .NET 5 will be supported on multiple operating systems.
  • CoreFX will be expanded to support static .NET compilation (ahead-of-time - AOT), to reduce resource consumption (footprints) and 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”.

Enforcement 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 performing environment used as part of Xamarin.

CoreCLR is the runtime used as part of .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 for 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 start, .NET relied on JIT compiler to convert Intermediate Language code in optimized machine code. We created industry-leading 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 speed, while at the same time creating a finely tuned version of the code if some methods are used frequently.

Our efforts to speed up ASP.NET Core work, as reflected in the benchmark results TechEmpower , are a good example of JIT capabilities and are our contributions to CoreCLR . We tried to prepare .NET Core to use 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 necessary 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-compile (ahead-of-time) compilation.

Fast start-up, low CPU consumption (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 be effectively executed with limited resources (small places), and, if necessary, sacrifice performance for their launch.

The project Blazor 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 where most of the code is AOT-compiled, but still allows the use of a JIT or 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 the appliance (appliance-like), which require a quick start and/or low consumption of processor resources.

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 launch 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, mostly Xamarin Blazor client tasks.

All .NET 5 applications can be built using the .NET CLI , so in all projects you will have a single command-based toolkit lines.

C # will evolve with .NET 5. Developers writing.NET 5 applications will get 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 .NET Core) and Unity talked about various technical capabilities and the direction of architecture development.

Now we move the project as a team. Since December, we have come a long way in several projects:

  • Defined the minimum level that defines the interaction between the runtime environment and the managed code layer, with the goal of making & gt; 99% CoreFX common code.
  • Now MonoVM can use CoreFX and its class libraries.
  • We ran all CoreFX tests on MonoVM using its implementation.
  • Run ASP.NET Core 3.0 applications on MonoVM.
  • Launch 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 text: [Translation] Introducing .NET 5