Today, we are announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET series.
In the future there will only be one .NET , with which you will be able to develop Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly, among others.
We're introducing new .NET APIs, runtime features, and language features in .NET 5.
Starting with the .NET Core project, we've added about fifty thousand .NET Framework APIs to the platform. .NET Core 3.0 fills most of the remaining feature gaps of .NET Framework 4.8, supporting Windows Forms, WPF, and Entity Framework 6. .NET 5 builds on this work, leveraging the best features of .NET Core and Mono to create a platform. You can use it for all modern .NET code.
We intend to release .NET 5 in November 2020 and launch the first preview in the first half of 2020. It will be supported in future updates for 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 the . NET：
- Build a .NET runtime and framework that can be used anywhere, with unified runtime behavior and developer experience.
- By taking full advantage of .NET Core, . NET Framework, Xamarin, and Mono to extend the capabilities of .NET.
- Building the product from a single codebase, developers (Microsoft and the community) can work together and extend together to improve all scenarios.
This new project and direction is a major turning point for .NET. With .NET 5, your code and project files will be the same no matter what type of application you are building. Each app has access to the same runtime, API, and language features. Also includes performance improvements to CoreFX, which are being made almost daily.
Everything you love about .NET Core will continue to exist:
- Open source and community-oriented on GitHub.
- Cross-platform implementation.
- Support leveraging platform-specific features such as Windows forms and WPF on Windows and native bindings for each native platform from Xamarin.
- High performance.
- Install side by side.
- Small project files (SDK style).
- Compatible with command line interfaces (CLIs).
- Visual Studio, Visual Studio for Mac, and Visual Studio Code integration.
There are also some new things:
- You'll have more options for your runtime experience (more on that below).
- Java interoperability will be available on all platforms.
- Multiple operating systems will support Objective-C and Swift interoperability.
- CoreFX will be expanded to support ahead-of-time (AOT) for .NET, a smaller footprint, and support for more operating systems.
We will release .NET Core 3.0 in September of this year, .NET 5 in November 2020, and then we intend to release a major version of the . NET：
We skipped version 4 because it would confuse users who are familiar with the .NET Framework, which has been around for a long time with the 4.x series. In addition, we want to clearly communicate that .NET 5 is the future of the .NET platform. Calling it .NET 5 makes it the highest version we've 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 a clarifying term like "Core". The shorter name is a simplification and also conveys the message that .NET 5 has uniform functionality and behavior. Of course, you can continue to use the name ".NET Core" if you wish.
Runtime experience
Mono is the original cross-platform implementation of .NET. It started as an open-source alternative to the .NET Framework and transitioned to mobile-specific with the popularity of iPhone/iOS and Android devices. Mono is a runtime that is used as part of Xamarin.
CoreCLR is a runtime that is used as part of .NET Core. It is primarily used to support cloud applications, including Microsoft's largest service, and is now also used in Windows desktop, IoT, and machine learning applications.
In summary, the .NET Core and Mono runtimes share many similarities (after all, they are both .NE runtimes), but they also have valuable unique features. It makes a lot of sense to make it possible to choose the runtime experience you want. We're making CoreCLR and Mono interchangeable with each other. We'll make it as simple as building a switch to choose between different runtime options.
The following sections describe the main focus we plan to use for .NET 5. They provide a clear perspective on how we plan to evolve these two runtimes individually and together.
High throughput and high productivity
From the beginning, .NET relied on just-in-time compilers (JITs) to convert intermediate language (IL) code into optimized machine code. Since then, we've built an industry-leading JIT-based managed runtime that has very high throughput and also 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 configured for specific machines, including specific CPU instructions. JIT can also regenerate methods at runtime, a technique that makes JIT faster, while still having the option to generate highly optimized versions of code if it becomes a frequently used method.
Our efforts to make ASP.NET Core run faster on the Techpower benchmark are a great example of the power of JIT and our investment in CoreCLR. Our efforts to harden .NET Core for containers are also a testament to the runtime's ability to dynamically adapt to constrained environments.
Developer tools are another great example of how JIT is really great, such as dotnet watch tools or edit and continue. Tools often need to compile and load code multiple times in a single process without restarting, and need to do this very quickly.
Developers using .NET Core or .NET Framework rely primarily on JIT. Therefore, the experience should be familiar.
The default experience for most .NET 5 working scenarios will use the JIT-based CoreCLR runtime. Two notable exceptions are iOS and client Blazor (web assembly), as they both require ahead-of-time (AOT) native compilation.
Fast startup, small footprint, and low memory usage
Most of the Mono project has focused on mobile and consoles. A key feature and outcome 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 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 Blazor project is already using Mono AOT. This will be one of the first projects to transition to .NET 5. We use it as one of the options to prove this plan.
There are two types of AOT solutions:
- Requires a solution that is 100% AOT compiled.
- Most code is an AOT-compiled solution, but JIT or interpreters can be used for code patterns that are not AOT-friendly (such as generics). Mono AOT supports both cases. Apple requires the first AOT for iOS and some consoles for security reasons. The second method is a better option because it offers the advantages of AOT and avoids some of the disadvantages.
.NET Native is our AOT compiler for Windows UWP applications, and is also an example of the first AOT type listed above. In this particular implementation, we limit the .NET API and the features you can use. We learned from this experience that AOT solutions need to cover all aspects of .NET APIs and patterns.
AOT compilation is still required on iOS, web assembly, and some consoles. For applications that require more quick startup or low footprint, we'll make AOT compilation an option.
The birth of the project
We started this project in December 2018 with a technical team in Boston. Design leaders from the .NET team (Mono/Xamarin and .NET Core) and Unity presented a variety of technical capabilities and architectural directions.
We are now moving this project forward as a team with a set of deliverables. We have made a lot of progress on a number of projects since December:
- A minimum layer is defined that defines the runtime <-> managed code layer with the goal of achieving >99% of CoreFX public code.
- MonoVM can now use CoreFX and its class libraries.
- Run all CoreFX tests on MonoVM with the CoreFX implementation.
- Run ASP.NET Core 3.0 applications with MonoVM.
- Run MonoDevelop on CoreCLR, then run Visual Studio for Mac.
Migrate 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 I code for a specific architecture? Do we still need .NET Standard?
We are working on these issues now and will soon share the design document for you to read and provide feedback.
Epilogue
The .NET 5 project is an important and exciting new direction for .NET. You'll see .NET become simpler, but also with a wider range of features and utility. All new developments and features will be part of .NET 5, including new C# versions.
We see a bright future where you can use the same .NET APIs and languages to target a wide range of application types, operating systems, and silicon architectures. In Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, or the command line, it's easy to change the build configuration to build different applications.
Original link:The hyperlink login is visible.
|
Posted on 5/7/2019 9:41:27 AM
|
|
|
|
