Announcing .NET 6 Preview 6

We are happy to release .NET 6 Preview 6. Preview 6 is the second to last preview before we enter the RC period. There will be two RCs. This release itself is relatively small, while Preview 7 will be bigger. After that, we’re down to quality fixes until the final release in November. We’re looking forward to a great new .NET release.

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

See the ASP.NET Core, EF Core and .NET MAUI posts for more detail on what’s new for web, data access, and client scenarios.

Starting with .NET 6 Preview 6, we’ve tested and support Visual Studio 2022 Preview 2. Visual Studio 2022 enables you to leverage the Visual Studio tools developed for .NET 6 such as development in .NET MAUI, Hot Reload for C# apps, new Web Live Preview for WebForms, and other performance improvements in your IDE experience. .NET 6 has also been tested with Visual Studio for Mac 8.9.

Check out the new conversations posts for in-depth engineer-to-engineer discussions of the latest .NET features.

x64 emulation update

We’re done adding support for Apple Silicon for macOS and Arm64 for Windows. What’s left is supporting x64 emulation on macOS Apple Silicon and Windows Arm64. We need to do two things to enable that.

Until side-by-side capable installers are available (later in .NET 6), you’ll either need to install all x64 builds or all Arm64 ones. If you want to switch, you need to uninstall/delete all .NET versions on your Arm64 machine. That’s unfortunate, but where we are at at this point.

Tools: .NET SDK Optional Workload improvements

We have added three new workload commands that enable better discovery and management.

• dotnet workload search — list workloads available to install.
• dotnet workload uninstall — remove the specified workload if you no longer require a workload. Also a good option for space saving.
• dotnet workload repair — re-install all workloads you’ve previously installed.
  • This is useful if your install fails in the middle because of a dropped internet connection.
  • Optional workloads are made up of multiple workload packs and you may have gotten into a state where some installed successfully but others didn’t.

In previous previews, we added the following commands:

• dotnet workload install — installs a workload.
• dotnet workload list — lists installed workloads.
• dotnet workload update — updates installed workloads.

Libraries: TLS support for System.DirectoryServices.Protocols

TLS support has been enabled for System.DirectoryServices.Protocols for Linux and macOS. It was already enabled for Windows. .NET users can now enjoy secure communications with LDAP servers.

Credit to @iinuwa.

Tools: Crossgen2 replaces crossgen

Crossgen2 has been enabled for all existing crossgen scenarios. With that milestone behind us, we’ve also removed (the old) crossgen from the SDK. It is no longer accessible and cannot be used.

Crossgen (1 and 2) enables pre-compiling IL to native code as a publishing step. Pre-compilation is primarily beneficial for improving startup. Crossgen2 is a from-scratch implementation that is already proving to be a superior platform for code generation innovation. For example, crossgen2 can generate code for a broader set of IL patterns than crossgen1.

The following MSBuild properties demonstrate how to enable pre-compilation with crossgen2.

      <!-- Enable pre-compiling native code (in ready-to-run format) with crossgen2 -->
      <PublishReadyToRun>true</PublishReadyToRun> 
      <!-- Enable generating a composite R2R image -->
      <PublishReadyToRunComposite>true</PublishReadyToRunComposite>

Libraries: Improved sync-over-async performance

Sync-over-async is a common type of blocking work. It can lead to starvation when it happens on thread pool worker threads. Slow thread injection may delay other queued work from running, and may delay the starvation from being resolved.

This change improved the rate of thread injection by default when sync-over-async is the only type of blocking work happening on thread pool worker threads. There are some new AppContext config values that can be used to configure the rate of thread injection in response to sync-over-async.

Runtime: W^X memory policy

We are enabling support for W^X memory protection. It is a requirement on Apple Silicon machines and a useful security measure on other operating systems.

This feature has an abnormal name. It should be read as “write exclusive execute”. That means that a memory page can be marked for read/write or read/execute but never any combination that includes write and execute. Write/execute pages are subject to being exploited with buffer overrun attacks, for example.

This feature requires changes throughout the product, wherever write/execute pages are used. For example, preview 6 includes a change that requires the JIT to cooperate with the W^X scheme we’ve adopted.

W^X is a requirement of macOS on Apple Silicon machines, optional in all other environments for .NET 6 and will likely be the default mode in all environments for .NET 7.

Note: The W^X implementation has a startup regression with .NET 6 on all environments but Apple Silicon. It will be resolved as part of .NET 7. The Apple Silicon implementation has no such regression due to operating system support for this scenario.

CodeGen changelog

The following codegen changes are included in Preview 6.

Dynamic PGO

• Add option to choose guarded devirt class randomly https://github.com/dotnet/runtime/pull/53399
• pgo/devirt diagnostic improvements https://github.com/dotnet/runtime/pull/53247

• Refactor LSRA heuristics selection https://github.com/dotnet/runtime/pull/52832
  • Now, DEBUG mode includes a COMPlus variable that LsraOrdering will let the user set the heuristics ordering.
  • Tune the heuristics for register to select optimal register candidate to spill. https://github.com/dotnet/runtime/pull/53853

The following improvements are based on these changes.

More improvements:

Code quality

• Eliminate redundant “test” instruction https://github.com/dotnet/runtime/pull/53214

Closing

The release is quickly coming together and to an end. We’ll soon be addressing only the most pressing feedback, approaching the same bug bar that we use for servicing releases. If you’ve been holding on to some feedback or have yet to try .NET 6, please do now. It’s your last chance to influence the release.

Thanks for everyone who has contributed to making .NET 6 another great release.

Thanks for being a .NET developer.