Announcing .NET 5.0 Preview 6

Rich Lander [MSFT]

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:

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:

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 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.


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.


Discussion is closed. Login to edit/delete existing comments.

  • Eddie Garcia 0

    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?


  • Gustavo André 0

    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?

  • André Köhler 0

    Will it be possible to compile Windows Forms or WPF applications on a Linux build server?

  • S T 0

    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” ?

  • Jason S. Clary 0

    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 try to download a pre-built version rather than bootstrapping themselves by building the needed tools in the right order.

  • 辰 徐 0

    Is there any plan to support new Apple Silicon Mac?

Feedback usabilla icon