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:

• Windows and macOS installers
• Binaries
• Docker images
• Snap installer

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
  • Struct handling improvements
  • Optimization to remove redundant zero initializations
• ARM64 hardware intrinsics implementation progress
  • Implement Duplicate and DuplicateSelectedScalar
  • ASIMD Shift Intrinsics
  • Polynomial Multiply Long Intrinsics
  • Optimize Vector64 and Vector128.Create methods
  • Optimize ToScalar() and GetElement() to use arm64 intrinsic
  • Optimize ToVector128, ToVector128Unsafe and Vector128.GetLower()
• ARM64 generated code improvements: greatly reduced ARM64 code size
  • Optimize call indirect for R2R, Arm and Arm64 scenarios
  • Optimize virtual call stub for R2R and JIT

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:

• Enable calling get_runtime_delegate from app context
• Implement hdt_get_function_pointer

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

Rich Lander [MSFT] Program Manager, .NET Team

Follow