English original text:Introducing .NET 5
Chinese translation:Microsoft officially announced .NET 5
Today, we announce that the next release after .NET Core 3.0 will be .NET 5. This will be the next major release of the .NET series.
There will only be one .NET in the future, and you will be able to use it to develop Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly.
We will introduce new .NET APIs, runtime features, and language features in .NET 5.
Starting with the .NET Core project, we've added about 50,000 .NET Framework APIs to the platform. .NET Core 3.0 complements most of the remaining functional gaps in the .NET Framework 4.8 and supports Windows Forms, WPF, and Entity Framework 6. Built on top of this work, .NET 5 leverages the best features of .NET Core and Mono to create a platform that you can use for all modern .NET code.
We plan to release .NET 5 in November 2020 and the first preview release in the first half of 2020. It will be supported in 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 ways:
This new project and direction is an important turning point in .NET. With .NET 5, your code and project files will be the same no matter what type of application you are building. Each application can access the same runtime, API, and language features. Also includes corefx that is being performed almost every day.Performance improvement.
Everything you like about .NET Core will continue to exist:
There are also some new things:
We will release .NET Core 3.0 in September this year, release .NET 5 in November 2020, and we plan to release the major version of .NET every November:
We skipped version 4 because it would confuse users familiar with the .NET Framework because the .NET Framework has been using the 4.x series for a long time. In addition, we want to clearly communicate that .NET 5 is the future of the .NET platform. Call it .NET 5 to make it the highest version we have ever released.
We also take this opportunity to simplify the naming. We think that if only one .NET is the best, we don't need clarification terms like “Core”. The shorter name is a simplification that also conveys information about .NET 5 with uniform functionality and behavior. Of course, you can continue to use the name “.NET Core” if you wish.
Mono is the original cross-platform implementation of .NET. It was originally an open source alternative to the .NET Framework and was turned into a mobile device with the popularity of iPhone/iOS and Android devices. Mono is the runtime used as part of Xamarin.
CoreCLR is a runtime that is used as part of the .NET Core. It is primarily used to support cloud applications, including Microsoft's largest service, and is now also used for Windows desktops, IoT and machine learning applications.
All in all, the .NET Core and Mono runtimes have many similarities (after all, they are all .NE T runtimes), but they also have valuable unique features. It makes sense to make it possible to choose the runtime experience you need. We are making CoreCLR and Mono interchangeable. We will make it as simple as building a switch to choose between different runtime options.
The following sections describe the main focus of our plans for .NET 5. They provide a clear perspective on how we plan to work separately and together.
High throughput and high productivity
From the beginning, .NET relied on the Just-In-Time Compiler (JIT) to translate intermediate language (IL) code into optimized machine code. Since then, we've built an industry-leading JIT-based managed runtime that delivers very high throughput and improves the developer experience, making programming fast and easy.
JIT is ideal for long-running cloud and client scenarios. They are able to generate code for specific machine configurations, including specific CPU instructions. JIT can also be run at runtimeRegeneration methodThis makes JIT faster technology, while still choosing to generate highly optimized code versions (if this becomes a frequently used method).
We are working hard to make ASP.NET CoreTechpower benchmarkRunning faster, this is a great example of the power of JIT and our investment in CoreCLR. We areContainer hardening .NET CoreEfforts have also demonstrated the ability of the runtime to dynamically adapt to a restricted environment.
Developer tools are another great example of JIT, such as
Dotnet watchTool or
Edit and continue. Tools often need to compile and load code multiple times in a single process without rebooting and need to do this very quickly.
Developers using .NET Core or the .NET Framework rely primarily on JIT. Therefore, this experience should be familiar.
The default experience for most .NET 5 work scenarios will use the JIT-based CoreCLR runtime. Two notable exceptions are iOS and client Blazor (web assembly) because they all require an early-of-time (AOT) native compilation.
Quick start, small footprint, low memory usage
Much of the energy of the Mono project is focused on mobile and gaming consoles. A key feature and result of the project is the .NET AOT compiler based on the industry-leading LLVM compiler project. The Mono AOT compiler allows .NET code to be built into a native code executable that can be run on a computer, just like C++ code. AOT-compiled applications can run efficiently in smaller locations and exchange throughput for startup when needed.
The Mono AOT is already in use in the Blavor project. This will be one of the first projects to transition to .NET 5. We use it as one of the solutions to prove this plan.
There are two types of AOT solutions:
.NET Native is our AOT compiler for Windows UWP applications and is the first AOT type example listed above. In this particular implementation, we have limited the .NET API and the features you can use. We have learned from this experience that AOT solutions need to cover all aspects of the .NET API and patterns.
AOT compilation is still needed in iOS, web assembly and some consoles. For applications that require a quick start or low footprint, we will make AOT compilation an option.
The birth of the project
We started this project with a technical team in Boston in December 2018. Design leaders from the .NET team (Mono/Xamarin and .NET Core) and Unity introduced various technical capabilities and architectural directions.
We are now advancing this project as a team and providing a set of deliverables. Since December, we have made a lot of progress on some projects:
Migrating to a single .NET implementation raises some important questions: What will the target framework be? Are the NuGet package compatibility rules the same? What workloads should the .NET 5 SDK support? How do you write code for a specific architecture? Do we still need .NET Standard? We are currently working on these issues and will soon share the design documentation for you to read and provide feedback.
The .NET 5 project is an important and exciting new direction for .NET. You'll see that .NET is much simpler, but it also has a wider range of features and usability. All new developments and features will be part of .NET 5, including the new C# version.
We see a bright future where you can use the same .NET API and language for a variety of application types, operating systems, and chip architectures. In Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, or the command line, you can easily change the build configuration to build different applications.