Announcing .NET 6 Preview 6

Richard Lander

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

LSRA

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

image image image

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.

41 comments

Comments are closed. Login to edit/delete your existing comments

  • Sin

    As a developer, I need to get a smaller size in the desktop AOT, need to get better performance in the server AOT, which is my very important needs, and Microsoft should also understand this reason, but always because “Oh, this seems to be some trouble, so let’s talk about the next version”, and not to really go all out to promote this thing, always come up with some compromise to comfort developers.
    I would like to see a console program of 100K instead of 100K*300, like C++, and I don’t want my WPF program to be a 130M standalone package.
    Avoiding the problem can never solve the problem, AOT you have to face sooner or later.

    • Max Mustermueller

      Yes, size is a problem. However look at https://github.com/dotnet/runtimelab/issues/524#issuecomment-753642105 “We do not plan to work on reducing .dlls down to 100kB as part of this experimental project.”. And for WPF this is because WPF does not support trimming. And it probably never gets support as WPF repo is owned by WinUI team now and besides of having not enough time, they also have not much clue about C#. This is why even when users commits something, like a FolderBrowser, it never gets reviewed / never gets merged.

      WPF repo should get a new dedicated and motivated team with C# experts.

  • Alexey Leonovich

    Starting with .NET 6 Preview 6, we’ve tested and support Visual Studio 2022 Preview 2.
    What exactly do you mean? Visual Studio 2022 is tested and supported in addittion to Visual Studio 2019? Is it still possible to develop applications for .NET 6 preview 6 with Visual studio 2019?

  • Ian Marteens

    Honestly, I’m not impressed at all by .NET 6. I’m seeing even regressions in performance in some of my projects. The times for reaching the low-hanging fruits are over.

    • Ian Marteens

      Working with WPF and .NET Core is a nightmare, on the other hand. Visual Studio constantly hangs.

  • Gianluca Pivato

    dotnet workload list and search return an empty list
    dotnet workload install maui doesn’t work
    dotnet new android doesn’t work

    what else shall I install other than the latest 6.0 sdk and VS 2022?