Today, we’re releasing .NET 5.0 Preview 6. It contains a small set of new features and performance improvements. The .NET 5.0 Preview 4 post covers what we are planning to deliver with .NET 5.0. Most of the features are now in the product, but some are not yet in their final state. We expect that the release will be feature-complete with Preview 8.
You can download .NET 5.0 Preview 6, for Windows, macOS, and Linux:
- .NET 5.0 release notes
- .NET 5.0 known issues
- .NET 5.0 Runtime epics
- GitHub release
- GitHub tracking issue
Windows ARM64 Update
We announced support for Windows ARM64 as part of Preview 4. At that time, we had only enabled console and ASP.NET Core apps on Windows ARM64. The Preview 6 SDK now includes support for Windows Forms. That means you can build and run Windows Forms apps on Windows ARM64 devices, just like you would on x64. We’re still working on adding support for WPF on Windows ARM64.
You can see a sample Windows Forms app running on an ARM64 laptop, shown below.
Visual Studio .NET remote debugger support for Windows ARM64 is expected with Visual Studio 16.7. We expect Visual Studio Code .NET remote debugger support to follow soon after that. To avoid confusion, this support is referring to running Visual Studio or Visual Studio Code on an x64 machine, and remote attaching to a running .NET application on a Windows ARM64 machine. In addition, Visual Studio Code is adding support for ARM64. We will support the C# extension and the .NET debugger running within the Windows ARM64 version of Visual Studio Code, however, I don’t have dates to share yet for that.
Visual Basic users are used to being able to enforce that their applications are single-instanced (one instance launched at a time). This behavior is now available via WindowsFormsApplicationBase.IsSingleInstance. Here’s a great explanation of this behavior from Scott Hanselman. Credit: @paul1956
You can see the result shown below.
RyuJIT code quality improvements
The RyuJIT team continues to land really important improvements, preview after preview. They didn’t disappoint with Preview 6. Let’s take a look:
- General improvements
- ARM64 hardware intrinsics implementation progress
- ARM64 generated code improvements: greatly reduced ARM64 code size
Single file apps
We’ve been continuing to improve Support Single-File Apps in .NET 5 . Our goal is to enable publishing an app as one file (obviously), for Windows, macOS and Linux. We’re almost there. When we last talked about single file, with Preview 4, I mentioned that Windows “single file” apps required a few extra runtime files. We added a new option to include native binaries and any additional content (like images) in the single-file. These files will be extracted upon first launch. Apps that target Linux and macOS don’t need to use this option for native runtime binaries, unless they want to use it for media or other content.
- On Linux, the singlefilehost with runtime components linked in is still to be implemented. Therefore, the runtime native binaries will be published as separate files (similar to Windows experience). #37119 , #38304
- On Linux, ready-to-run assemblies embedded in a bundle are loaded like IL assemblies. #38061
Native hosted application
Over the years, we’ve seen a variety of hosting models for .NET in native applications. @rseanhall proposed and implemented a novel new model for doing that, which takes advantage of all the built-in application functionality offered by the .NET application hosting layer (specifically loading dependencies), while enabling a custom entrypoint to be called from native code. That’s perfect for a lot of scenarios, and that one can imagine becoming popular with developers that host .NET components from native applications. That didn’t exist before. Thanks for the contribution, @rseanhall.
Two primary PRs:
[Breaking change] Removal of built-in WinRT support in .NET 5.0
Windows Runtime (WinRT) is the technology and ABI that new APIs are exposed with in Windows. You can call those APIs via .NET code, similar to how you would with C++. Support for WinRT interop was added in .NET Core 3.0, as part of adding support for Windows desktop client frameworks (Windows Forms and WPF).
More recently, we’ve been working closely with the Windows team to change and improve the way that WinRT interop works with .NET. We have replaced the built-in WinRT support with the C#/WinRT tool chain, provided by the Windows team, in .NET 5.0. This change in WinRT interop is a breaking change, and .NET Core 3.x apps that use WinRT will need to be recompiled. We will provide more information on this in coming previews.
The benefits are called out in Support WinRT APIs in .NET 5:
- WinRT interop can be developed and improved separate from the .NET runtime.
- Makes WinRT interop symmetrical with interop systems provided for other operating systems, like iOS and Android.
- Can take advantage of many other .NET features (AOT, C# features, IL linking).
- Simplifies the .NET runtime codebase (removes 60k lines of code).
For more details, see the official docs issue at https://github.com/dotnet/docs/issues/18875. To see all breaking changes (in dotnet/runtime) in the release, check out the .NET 5.0 breaking change query.
We’ve updated our .NET 5 – Supported OS versions page to capture our latest plans for platform support for .NET 5.0. Please tell us what you think. What are we missing?
We realized that the package manager and container support we offer isn’t listed on that page. That should be fixed. We plan to add that information before we release .NET 5.0.
We’re now past the half-way point in this release cycle. In fact, we’re starting to (in our parlance) “close down the release”. If you are watching our repos closely, you’ll see that we’re starting to manage the milestones of issues more carefully. Having worked on multiple .NET releases now, I can tell you that this is a great time. It’s time to claim victory on the set of features we’ve built, and to polish them to the point that you are happy using them. That’s what we’re doing now, in our home workplaces.