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.
- Installers and binaries
- Container images
- Linux packages
- Release notes
- API diff
- Known issues
- GitHub issue tracker
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.
- Side-by-side capable installers
- First-class architecture targeting with the .NET CLI to (primarily) enable using the native architecture SDK in all scenarios.
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
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.
The following codegen changes are included in Preview 6.
- 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.
- Eliminate redundant “test” instruction https://github.com/dotnet/runtime/pull/53214
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.
Are you still planning on improving the missing runtime message? See here.
.NET 6 will be very disappointing, unless you are interested into Arm64. Most of what people expected from JSON is now moved to 7.0 (includes stuff people have been asking for since .NET 3 btw). Still no proper AOT which people are asking for since .NET 3. Dont forget, it was being announced and then silently removed from roadmap where if you ask for it now, you will get “We have AOT and if that doesn’t meet your expectation, sorry. No further plans” as answer.
Hopefully, next year will be better.
A relatively small part of the team is focused on Arm64. It’s super important, but hardly the primary deliverable for the release. The Preview 4 post does a good job of capturing the broad feature set and value proposition of the release. I’ll leave that for you and others to consider. https://devblogs.microsoft.com/dotnet/announcing-net-6-preview-4/
Totally agree! I’m hoping that .NET 7 will be better than .NET 6, too.
We know you and others want a “real AOT” experience. I encourage you to look at our NativeAOT project. It continues to plug along, as an experiment. It would be great to know if it meets your needs (as an experiment or otherwise). https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
I can see where @Max feels underwhelmed by Dot Net 6, but personally I’m looking forward to it since there’s so much more.
I have not had a chance to test out CrossGen2 yet with .NET 6, but I am looking forward to it due to the fact that we use WPF at my company and we are always trying to find ways to make the user experience better. That being said, I was hoping to find some benchmarks comparing CrossGen2 to CrossGen and NGen but I haven’t been able to find any in your recent blog posts. Have you done any or know of any? If I am overlooking it, I apologize in advance.
Latest on AOT support for WPF is here: https://github.com/kant2002/WinFormsComInterop/issues/1#issuecomment-879620008
“They are slow to react on the matter, so chances that it would be slow process.”
They are slow to react because WPF repo is now owned by the WinUI team, which seems to have not much idea about C#. All they are doing is running tests and only accept commits which does not add/remove or modify too much code as they cannot properly review them, in fact, they NEVER review them. Dozen of user commits has been left without a review for months or even years, still.
If AOT support for WPF relies on having the WPF team to do something, then WPF never gets AOT. It doesn’t even get trim support. But WPF is the most used .NET Windows desktop UI framework. It looks more and more that if your company develops for Windows desktop, .NET is becoming more and more not a choice at all. All new features in .NET are not available for you and WinUI is too far away from being a serious replacement.
What people have been simply asking for about the topic “AOT” is that they need to deploy some native application as their product, which does not only mean that the so-called “AOT” is “AOT”, but also means it should come with product level support.
As the most expected and frequently asked feature since the age of .NET Framework, AOT has been unreasonably and indefinitely put off by the .NET official teams, with all kinds of excuses and distortions given.
Let’s enumerate the history of the failed introductions, excuses and distortions on AOT, given by the official team:
1. .NET Native, which is initially introduced as a feature of .NET Framework, ended up with UWP(Who cares?)-only. “We made it, but with limited usage!”
2. CoreRT, which is initially introduced as one of the two runtime solutions of the first version of .NET Core, was announced as “coming soon” and indefinitely put off. “We made it, but be patient until it is product-ready.”
3. R2R, another irrelative optimization feature, along with SFP, was introduced as a distortion of the commonly known concept ‘AOT’. Whenever people asked about ‘AOT’, they are misled to R2R with SFP. The official team forged a new concept ‘native AOT’ from the void, which refers to what is commonly known as ‘AOT’. “AOT? Yes we do. But if it does not meet your expectation, it is because you confused the concept ‘AOT’ with ‘native AOT’.”
4. Native AOT, which is a reform (or just a rename because of the newly forged concept ‘native AOT’) of CoreRT, marked as an experimental project and thrown into the “runtimelab” repo as a branch, along with the experimental projects that few people cares. “We are taking new actions on it, be patient!”
5. A survey about how people expect the real AOT, was released by the official team, since the R2R distortion has been widely questioned. “Ah, we see. To our surprise, your AOT is native AOT! we have failed to imagine how you have been looking forward it in the past decade! Let’s forget about the misunderstanding and probably we could move on soon!”
6. Blazor WebAssembly AOT workload in .NET 6, which sounds nice, but again, it is for a certain use only (though it is a lot more useful than UWP), not for general purpose, and hopefully there should not be another excuse, but if there really is, it could be like “We have supported native AOT already, and we don’t think the other targets need it”.
7. Up to now, there is unlikely to be any further excuses, but only “Yes, we have an experimental solution for your production!”.
You summed it up pretty well.
Right now I think the only way to mount pressure is adopt Java, Go, Rust, heck even D, if the libraries required for the project are available in production quality.
If companies start moving away from .NET for AOT deployment scenarios, then the pressure will finally be there to actually deliver the AOT that should have been there since .NET 1.0.
You also forgot to mention that Singularity and Midori projects also used proper AOT, the one that they don’t understand what we meant by AOT.
You said everything, I’m looking in the Native AOT from the age that .net native for UWP became true, but sadly isn’t done yet. And I hope when the microsoft do it, will be possible just like the CoreRT create UEFI binaries and drivers using only C#, to not be windows-only feature.
Your comment is too long, so I cannot read it.
NativeAOT is what I meant with “you will get “We have AOT and if that doesn’t meet your expectation, sorry. No further plans” as answer.”. NativeAOT does not work with WPF and Winforms and there are no plans to support them, at least nowhere on any official roadmap I’ve seen. Not even publishing with WinUI 3 (C# project) generates AOT binaries! This cuts NativeAOT down to libraries or console projects only, at least for desktop development. Furthermore, a simply hello world published using NativeAOT is about 2mb large, while using an unmanaged language such as C++ or Delphi I get binaries in 100kb or less. People reported this but also get “No plans to improve this in the future” as answer.
This makes NativeAOT be a “We have AOT, but its limited and if that doesn’t meet your expectation, sorry. No further plans”.
Our answer for AOT scenarios should turn into “sorry, new application will be written in Java, Go, Rust, D,….”.
Assuming the AOT decision trend is to keep going as during the last five years.
Actually productization of NativeAOT on windows is in progress (https://github.com/kant2002/WinFormsComInterop, https://github.com/microsoft/microsoft-ui-xaml/issues/5398) . Currently Winforms is well in progress, WPF is started, WinUI is being investigated. This is all being done by one person (kant2002) because Microsoft has not officially decided whether apps on Windows are important.
You CAN already publish native executables using NativeAOT. But what you cannot do is publishing native executables using an UI framework, such as Winforms, WPF, WinUI. I dont see how bflat can help with this problem. And when developing software which is sold to customers you definitely not want to rely on something where support isn’t guaranteed.
There are a lot of people out there who can only devote time to LTS releases, and I assure you we are not disappointed…
Anyone else having issues publishing Blazor WASM from VS with .NET 6 ? Setting the deploy type to “stand alone” causes several errors for us. Perhaps someone at Microsoft has an idea how we should publish our Blazor WASM project using .NET 6 to Azure Storage?
Severity Code Description Project File Line Suppression State
Error Assets file ‘….\obj\publish\browser-wasm\project.assets.json’ doesn’t have a target for ‘net6.0’. Ensure that restore has run and that you have included ‘net6.0’ in the TargetFrameworks for your project
Severity Code Description Project File Line Suppression State
Error The imported project “C:\Program Files (x86)\Microsoft Visual Studio\2019\Preview\Common7\IDE\microsoft.netcore.app.runtime.mono.browser-wasm\6.0.0-preview.6.21352.12\runtimes\browser-wasm\native\src\Emcc.props” was not found. Confirm that the expression in the Import declaration “C:\Program Files %28×86%29\Microsoft Visual Studio\2019\Preview\Common7\IDE\microsoft.netcore.app.runtime.mono.browser-wasm\6.0.0-preview.6.21352.12\runtimes\browser-wasm\native\src\Emcc.props” is correct, and that the file exists on disk.
Hi Tim. Thanks for trying out this latest .NET 6 preview! To help us figure out what’s going on here, could you please open a GitHub issue with test exact steps that reproduce the problem you are seeing?: https://github.com/dotnet/aspnetcore/issues/new. Hopefully we’ll get this sorted soon!
I’ve submitted the issue on GitHub. Thanks for replying.
Just as a general question, what are the ideal publish settings for VS when deploying a Blazor WASM app to Azure Storage?
We currently have a CDN configured in front of Azure Storage and copy over the published files from the publish folder to Azure Storage using Azure Storage Explorer. This makes for a quick and easy way to deploy for testing without having to setup any automated deployment.
Will Blazor WASM apps run from an Azure Storage blob if published using “framework-dependent” and “Portable”? Are there more optimal publish settings when hosting Blazor WASM from a folder (Storage)?
Hi, I have the same problem. Has anyone solved this problem?
I have the same issue. Is there a solution posted anywhere?
And where is C# 10?
C# 10 is already part of .NET 6 previews.
You activate it by adding a LangVersion element set to preview in your project file.
To test it, I recommend following these steps:
You can read about the new C# 10 features here: https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-10
Well, what I mean by C# 10 is actually the primary features that define how users are looking forward to it, like:
1. Fully typed lambda expression with support for ref, explicit return type, and many others.
2. Value type record.
Adding to the “what’s new” link already shared – the milestone that tracks this is at https://github.com/dotnet/csharplang/milestone/20
What we want
.Net 6 + WinUI 3 + UWP
I’m still hoping that #40704 will make it in.
Its on the milestone but there doesn’t seem to be any activity 🙁
Ctrl + F -> input “AOT” -> Can not find it in content -> Close browser tab
Most commands related to dotnet workload never worked for me. I somehow managed to install some workloads after preview 5 was released but now I am unable to update them nor reinstall them. I am getting below error:
I don’t see any such folder in the temp folder.
Hi Richard, Does this preview support Entity Framework Core migration?
EF Core already has migrations in current version.
Does not work on Windows 7.
Form.Font = new System.Drawing.Font(“Consolas”, 9F, System.Drawing.FontStyle.Regular, System.Drawing.GraphicsUnit.Point);
if not complicated, implement user32::AdjustWindowRectExForDpi for win 7, 8, 8.1
When I Update the sdk from .net6 p 5 to p6 and run the winformapp in win7sp1 OS,I got the exception “unable to find an entry point named ‘AdjustWindowRectExForDpi’ in DLL user32.dll”.
detail with gift