![Rich Lander [MSFT]](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/letter-avatar/cb895f2fa6fae6447bab144d4f3ec4b3.svg){kind=avatar}
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:
ASP.NET Core and EF Core are also being released today. Note: EF Core 5.0 will not support .NET Standard 2.0 or .NET Framework. Read the EF Core post to learn more.
You need to use Visual Studio 2019 16.7 to use .NET 5.0. .NET 5.0 is now supported with Visual Studio for Mac. Install the latest version of the C# extension, to use .NET 5.0 with Visual Studio Code.
Release notes:
- .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.
Windows Forms
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
The team added Collapse Support to ListViewGroup. This change makes it easier to manage a form with multiple ListViewGroups. Credit: @lonitra (.NET Team intern).
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.
Current limitations:
- 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.
Platform support
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.
Closing
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.
Is there any plan to support new Apple Silicon Mac?
Official GNU/Linux arm64 SDK support will be nice. The only thing better would be support for non-GNU Linux like those using Bionic (Android) and musl in place of glibc. That way I could avoid installing a huge Debian proot under Termux on Android just to use dotnet.
Just documenting how to build on a platform that doesn't already have a pre-built SDK would be a nice compromise. The build scripts for dotnet/sdk and dotnet/installer both...
Hello Microsoft.
Looking forward to .NET 5.0 but we also need to know how to block the installation on those app servers where its not supported.
Is the registry key to block it, “BlockNetFrameWork50” and set the value to “1” ?
Will it be possible to compile Windows Forms or WPF applications on a Linux build server?
So, on the switch from preview 4 to preview 5, the supported C# version changed from C# 8.0 to C# 9.0-preview, but none of the announcement posts say which parts of C# 9.0 were enabled with this change. Is there any place where we can find this information?
I am trying to get my debugger visualizer to work on core. Is there a walkthrough somewhere on how to port your debug visualizers? Is it supported? If not will it be before .net 5 RTM?
Thanks,
-E
Will coreclr add hybrid mode that already run in mono, allow coreclr interpreter, jit, aot mixed run at the same time?
How is the Apple’s decision of migrating from Intel to Apple’s own chips going to affect the .Net?
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?
Still missing Linux x86 :(
Linux x86 is still really important because of the lower memory usage - even Microsoft uses 32-bit by default in their Windows-based Azure App Services. There have been popular issues open about this in GitHub for years, and I'd...
still waiting for native static AOT compilation..
why you so hesitant on talking about it, it’s almost like you despise this feature many are waiting for
we need more transparency, it was announced last year, and since then, radio silence
Also still waiting. But Lander already said they will tell more about it in Preview 7 and this is only about Preview 6. Finger cross it will work with WPF applications too….