Introducing .NET 5.0 Preview 6

Last week we released .NET 5.0 Preview 6. The version contains a small set of new features and performance improvements. The .NET 5.0 Preview 4 post is dedicated to what we plan to release in .NET 5.0. Most of the features are currently implemented, but some are not yet in their final state. We expect the release to be fully functional with Preview 8.



You can  download .NET 5.0 Preview 6 , for Windows, macOS and Linux:

• Windows and macOS installers
• Full list
• Docker Images
• Snap installer

ASP.NET Core  and  EF Core  were also released last week. Note: EF Core 5.0 will not support .NET Standard 2.0 or .NET Framework. Read  the EF Core release post to find out more.



You need to use  Visual Studio 2019 16.7  to work with .NET 5.0. .NET 5.0 is now supported in  Visual Studio for Mac . Install the latest  C # extension to use .NET 5.0 with  Visual Studio Code .



Notes:

• .NET 5.0 Release Notes
• .NET 5.0 Known Issues
• Release on GitHub
• Issue tracker on GitHub

Windows ARM64 update

We announced support for Windows ARM64 as part of Preview 4 . At the time, we only included console and ASP.NET Core apps on Windows ARM64. SDK Preview 6 now includes support for Windows Forms. This means that you can create and run Windows Forms applications on Windows ARM64 devices, just like on x64. We are still working on adding WPF support to Windows ARM64.



You can see an example of a Windows Forms application running on an ARM64 laptop, as shown below.







Visual Studio 16.7 expects support for the Visual Studio .NET remote debugger for Windows ARM64. We expect that soon after this, support for the Visual Studio Code .NET remote debugger will appear. To avoid confusion, this support applies to running Visual Studio or Visual Studio Code on an x64 machine and remotely connecting to a running .NET application on a Windows ARM64 machine. In addition, Visual Studio Code adds support for ARM64. We will add support for the C # extension and .NET debugger, which work in the version of Visual Studio Code for Windows ARM64, but the dates are still unknown.

Windows Forms

Visual Basic users are used to having their applications single-instanced (one instance starts at a time). This behavior is now available through WindowsFormsApplicationBase.IsSingleInstance . Here's a great explanation for this behavior from Scott Hanselman.



The team added collapsing support to the ListViewGroup. This change makes it easier to manage a form with multiple ListViewGroups.



And here is the result:

Improving RyuJIT Code Quality

The RyuJIT team continues to make some really important improvements, preview by preview. They didn't disappoint in Preview 6. Let's see:

• Major improvements
  
  
  • Struct Improvements
    
    
  • Optimization to remove redundant zero initializations
• ARM64 Hardware Embedded Function Implementation Progress
  
  
  • Duplicate DuplicateSelectedScalar
  • ASIMD Shift Intrinsics
  • Polynomial Multiply Long Intrinsics
  • Vector64 Vector128.Create
  • ToScalar() GetElement() arm64
  • ToVector128, ToVector128Unsafe Vector128.GetLower()
• ARM64: ARM64
  
  
  • R2R, Arm Arm64
  • virtual call stub R2R JIT
  
  
  

We continue to improve support for single-file applications in .NET 5. Our goal is to make it easier to publish your application as a single file for Windows, macOS, and Linux. We're already close. When we last talked about this in Preview 4 , I mentioned that Windows “single file” applications require a few extra runtime files. We've added a new option to include native binaries and any additional content (like images) in one file. These files will be extracted on first launch. Applications designed for Linux and macOS should not use this option for native runtime binaries unless they want to use it for multimedia or other content.



Current limitations:

• Linux runtime- . ( Windows).
• Linux , , IL.

-

Over the years, we have seen many hosting models for .NET in native applications. @rseanhall proposed and implemented a new new model for this, which uses all the built-in application functionality provided by the .NET application hosting level (in particular, loading dependencies), while at the same time allowing you to call a custom entry point from native code. This is ideal for many scenarios, and it is understood that this is becoming a popular method among developers who place .NET components from native applications.



Two main PRs:

• Enable get_runtime_delegate call from application context
• Hdt_get_function_pointer implementation

Platform support

We've updated our .NET 5 - Supported OS Versions page to reflect our latest plans to support the .NET 5.0 platform. Please tell us what you think. What are we missing?



We know that the package manager and container support we offer is not listed on this page. This should be fixed. We plan to add this information prior to the release of .NET 5.0.