Announcing .NET 6 Preview 2

Richard Lander

Today, we are glad to release .NET 6 Preview 2. It includes new APIs, runtime performance improvements, and early builds of .NET MAUI. It also includes builds for Apple Silicon, which were missing for Preview 1. After the announcement of the overall .NET 6 release, we’re now back to regularly scheduled monthly previews until the final release in November. You will see new features included in each preview that deliver on .NET 6 themes, epics and user stories. These themes offer improvements to every .NET application, including for server/cloud, desktop, IoT and mobile.

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

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

.NET 6 has been tested with Visual Studio 16.9 and Visual Studio for Mac 8.9. We recommend you use those builds if you want to try .NET 6.

In this post, two of my team members will cover the .NET 6 themes that they are working on, specifically Improve inner-loop performance for .NET developers and .NET has a great client app development experience. I covered Improve startup and throughput using runtime execution information (PGO) in the .NET 6 Preview 1 post.


.NET 6 will be released in November 2021 and will be supported for three years, as a Long Term Support (LTS) release. The platform matrix has been significantly expanded compared to .NET 5.

The additions are:

  • Android.
  • iOS.
  • Mac and Mac Catalyst, for x64 and Apple Silicon (AKA “M1”).
  • Windows Arm64 (specifically Windows Desktop).

.NET 6 Debian container images are based on Debian 11 (“bullseye”), which is currently in testing.

Theme — Improve .NET Inner Loop Performance

Stephen Toub is the author of this theme section. He’s part of the team working on the inner loop theme, and is sharing his team’s goals and plans.

Performance is top of mind for all .NET releases. Over the past several versions, a lot of effort has gone into improving throughput, reducing memory consumption, and other factors that impact the steady-state performance of an application. For .NET 6, we’re also focused on a few additional aspects, several of which are highlighted as part of one of the .NET 6 themes: improving inner-loop performance for .NET developers. Just as we’ve focused on ensuring that apps and services have the best possible performance, we also want to ensure that developers are able to be as productive as possible, optimizing the tools and workflows that are frequently used as part of their “inner loop” (meaning the processes they use repeatedly as part of making code changes, building, and testing).

Some of these efforts look very similar to traditional throughput efforts of the past, but instead of focusing on steady-state performance, they’re focused on startup performance, of the runtimes, the app models, the dotnet CLI, MSBuild, etc., as well as the end-to-end performance of the tools (especially for smaller solutions, as historically they haven’t received as much attention). The mindset involved in such optimizations is often quite different from the mindset used when optimizing for steady-state throughput. For steady-state work, you might focus on caching values that could be reused in the future, but often for startup performance you’re focused on operations that may only be invoked once and where the costs for that first invocation matter. The work involved here does, however, look like many other performance efforts, with a typical profile-analyze-fix loop: you profile the relevant area of the application you want to optimize, you analyze the resulting data to look for the top offenders and bottlenecks, you come up with fixes for them, and then you start the process over to find the next impactful items. We’re still early in the .NET 6 development cycle, but we’ve already been successful in trimming overheads from key areas involved in developers’ inner loops, focusing on various dotnet commands like new, build, and run. Example improvements thus far include fixing places tools were unexpectedly JIT’ing (dotnet/installer #9635), avoiding expensive logging-related work happening even when logging wasn’t enabled (dotnet/aspnetcore #27956), optimizing globbing in MSBuild (dotnet/msbuild #6151), changing the ASP.NET Razor compiler to use a Roslyn source generator in order to avoid an extra compilation process (, and changing the .NET host to use file access patterns less likely to trigger antivirus tooling on the machine (dotnet/runtime #48774).

Of course, one of the best performance optimizations is one that avoids the need for work to be done entirely, and that is the focus of the other half of this .NET 6 theme: .NET hot reload. Hot reload will improve developer productivity, across all supported operating systems and hardware platforms, by enabling code to be edited while an app is running, even without a debugger attached. With many kinds of edits, no restart will be required: the developer will save their changes, and the new version of the code will be applied to the executing process. Upon wanting to make a change to the app or service, rather than needing to stop it and go through the typical inner loop cycle of making the change, building, running, and getting back to the point in the app or service that triggered the need for the change in the first place, that whole cycle can be skipped for many kinds of edits. The work involved in enabling this spans the .NET release, requiring investments in the runtimes (both coreclr and mono), the C# Roslyn compiler, the app models (for example, Blazor, .NET MAUI), and the developer tools (for example, CLI, Visual Studio), but it is expected to fundamentally improve the way .NET developers go about writing their apps and services.

Image dotnet6 build improvements

The chart above demonstrates some early results of the inner loop effort.

Theme: .NET has a great client app development experience

Maddy Leger is the author of this theme section. She is part of the team working on the client app development theme, and is sharing her team’s goals and plans.

One of the most exciting parts of .NET 6 is mobile development, which is currently offered as the separate Xamarin product. Over time, we’ve been making Xamarin more similar to mainline .NET. It’s now time to deliver a fully unified mobile product for .NET. With .NET 6, iOS, Android, and macOS development will be integrated into the .NET SDK experience and use the .NET libraries. For the past couple years, we’ve been working to fold Mono into .NET, so developers can leverage the strengths of both runtimes without having to target different .NET versions or worry about compatibility issues. In .NET 5, we moved Blazor WebAssembly over, and are using that same model for Xamarin. .NET 6 is the culmination of this unification effort, encompassing a key Epic of the theme – Xamarin developers can upgrade to and use the latest .NET SDKs for their existing apps.

Now that all your .NET apps will run on the same libraries, we want to increase the amount of code you share across desktop and mobile platforms. Xamarin.Forms, Xamarin’s cross-platform UI framework, is evolving into .NET Multi-platform App UI, enabling you to easily write apps for iOS, Android, Windows, and macOS with the same codebase. .NET MAUI is shipping as part of .NET 6 along with a bunch of performance and tooling improvements like .NET/C# Hot Reload, more shared resources and code across different platforms, and better page rendering performance with a more flexible set of UI controls. You can follow the overall Epic: Xamarin/.NET MAUI developers have improved app performance and share more code with .NET 6.

.NET MAUI isn’t just for client app developers. Thanks to the refactored control set and the ability to run on the .NET 6 libraries, your existing Blazor apps will run natively on Windows and macOS via .NET MAUI. You’ll be able to seamlessly weave in native controls and functionality alongside your Blazor codebase, including platform specific functionality. See the Preview 1 blog for some screenshots of “Blazor desktop” in action.

The final epic we’re focused on in this theme is about packaging, deploying, and releasing your cross-platform client apps. Because there are so many developers/target platforms/ways to develop your apps, there are a lot of different app packages you have to distribute at the end of the day. Especially with Blazor desktop, we want to make that experience as seamless as possible. We’re looking at strategies for improving release and versioning both locally and in the cloud as part of the epic Desktop developers can package, distribute, release, and update their applications to multiple desktop platforms and architectures.

To summarize, in .NET 6 you’ll be able to:

  • Build iOS, Android, and macOS apps using the .NET libraries.
  • Create iOS, Android, Windows, and macOS apps from the same codebase using .NET MAUI.
  • Share more code and resources across platforms (such as images, app icons/manifests, and more).
  • Run your Blazor web apps natively on the macOS and Windows.
  • Easily package and distribute your apps for all the target frameworks you include.

We’ve already made a lot of progress and will continue to add more features into each .NET 6 Preview. For more info, you can follow the .NET MAUI repo, which is kept up to date with progress reports.

The remainder of the post is dedicated to features that are new in Preview 2.

.NET Multi-platform App UI

We have added .NET MAUI and single project developer experiences for Android, iOS, and Mac Catalyst. We have updated our samples repository with projects you can run today with .NET 6 Preview 2. As we progress through previews, more and more functionality will be enabled. Today your best experience running these projects is via the command line.

Mac Catalyst

You can add the following TargetFramework settings to your project to build for macOS desktop, using Mac Catalyst.

<TargetFrameworks Condition=" '$(OS)' != 'Windows_NT' ">$(TargetFrameworks);net6.0-maccatalyst</TargetFrameworks>

A single, multi-targeted application project

We’ve now enabled a single project experience for .NET MAUI apps. You now get a very clean solution that can run on Android, iOS, and macOS. Windows support depends on WinUI 3 which is in its own preview now. We will add Windows to .NET MAUI in a future preview. See the roadmap for more details.

To use this today, follow the guidance in our samples repository to build and run from the command line. Future versions of Visual Studio will add device selections and run options.

single, multi-targeted application project

Shared fonts, images, and app icons

Fonts and images can be placed in one location in your solution and .NET MAUI will enable them to natively work on all platforms you target. These are tracked in your *.csproj as SharedImage and SharedFont.

    <SharedImage Include="appicon.svg" ForegroundFile="appiconfg.svg" IsAppIcon="true" />
    <SharedFont Include="Resources\Fonts\ionicons.ttf" />

Both accept wildcards to include all files within a location.

    <SharedImage Include="appicon.svg" ForegroundFile="appiconfg.svg" IsAppIcon="true" />
    <SharedImage Include="Resources\Images*" />
    <SharedFont Include="Resources\Fonts*" />

MauiApp with Host Builder for bootstrapping your app

We have extensions for configuring services, fonts, and compatibility renderers for migrating Xamarin.Forms projects. IWindow has been introduced for multi-window support coming in a future release. This new pattern also introduces a single, consistent place for library authors and control vendors to integrate with .NET MAUI.

public class Application : MauiApp
    public override IAppHostBuilder CreateBuilder() => 
            .ConfigureServices((ctx, services) =>
                services.AddTransient<IWindow, MainWindow>();
            .ConfigureFonts((hostingContext, fonts) =>
                fonts.AddFont("ionicons.ttf", "IonIcons");

    public override IWindow CreateWindow(IActivationState state)
        return Services.GetService<IWindow>();

New Control Handlers

We have introduced the first controls and properties that implement a new handler approach. These include partial implementations of Button, Label, and Entry, Slider, and Switch. We are now accepting pull requests to fill out complete implementations, and several contributors have already successfully contributed. For more information on joining the effort, visit the handler property guidelines.

The HelloMaui sample application now runs from a single project to macOS, iOS, and Android showcasing the current set of ported controls.

macOS: Screen Shot 2021-03-08 at 10 57 44 AM

iOS: Screen Shot 2021-03-08 at 2 39 34 PM

Android: Android emulator screenshot of .NET MAUI controls

Updates to Mobile SDKs

The mobile SDKs and surrounding tooling are gaining capabilities in this release as well. These capabilities will continue to improve as they are integrated with future Visual Studio releases.


  • Android X libraries are now available for .NET 6 and the default dependency for Android apps


  • Developers on Windows can use the Remote iOS Simulator
  • Developers on Windows can connect to the remote Mac build host
  • Ahead-of-time compilation has been added to enables building and deploying to physical iOS hardware

.NET Libraries

The following APIs and improvements have been added to the .NET libraries.

System.Text.Json – ReferenceHandler.IgnoreCycles

JsonSerializer (System.Text.Json) now supports the ability to ignore cycles when serializing an object graph. The ReferenceHandler.IgnoreCycles option has similar behavior as Newtonsoft.Json ReferenceLoopHandling.Ignore. One key difference is that the System.Text.Json implementation replaces reference loops with the null JSON token instead of ignoring the object reference.

You can see the behavior of ReferenceHandler.IgnoreCycles in the following example. In this case, the Next property is serialized as null since it otherwise creates a cycle.

class Node
    public string Description { get; set; }
    public object Next { get; set; }

void Test()
    var node = new Node { Description = "Node 1" };
    node.Next = node;

    var opts = new JsonSerializerOptions { ReferenceHandler = ReferenceHandler.IgnoreCycles };

    string json = JsonSerializer.Serialize(node, opts);
    Console.WriteLine(json); // Prints {"Description":"Node 1","Next":null}


PriorityQueue<TElement, TPriority> (System.Collections.Generic) is a new collection that enables adding new items with a value and a priority. On dequeue the PriorityQueue returns the element with the lowest priority value. You can think of this new collection as similar to Queue<T> but that each enqueued element has a priority value that affects the behavior of dequeue.

The following sample demonstrates the behavior of PriorityQueue<string, int>.

// creates a priority queue of strings with integer priorities
var pq = new PriorityQueue<string, int>();

// enqueue elements with associated priorities
pq.Enqueue("A", 3);
pq.Enqueue("B", 1);
pq.Enqueue("C", 2);
pq.Enqueue("D", 3);

pq.Dequeue(); // returns "B"
pq.Dequeue(); // returns "C"
pq.Dequeue(); // either "A" or "D", stability is not guaranteed.

Credit to community member Patryk Golebiowski for contributing the implementation.

Better parsing of standard numeric formats

We’ve improved the parser for the standard numeric types, specifically for .ToString and .TryFormat. They will provide better results when precision > 99 decimal places is specified. Also, the parser now better supports trailing zeros in the Parse method.

The following examples demonstrate before and after behavior.

  • 32.ToString("C100") -> C132
    • .NET 6: $32.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    • .NET 5: We had an artificial limitation in the formatting code to only handle a precision of <= 99. For precision >= 100, we instead interpreted the input as a custom format.
  • 32.ToString("H99") -> throw a FormatException
    • .NET 6: throws a FormatException
    • This is correct behavior, but it’s called here to contrast with the next example.
  • 32.ToString("H100") -> H132
    • .NET 6: throw a FormatException
    • .NET 5: H is an invalid format specifier. So, we should’ve thrown a FormatException. Instead, our incorrect behavior of interpreting precision >= 100 as custom formats meant we returned wrong values.
  • double.Parse("9007199254740997.0") -> 9007199254740998
    • .NET 6: 9007199254740996.
    • .NET 5: 9007199254740997.0 is not exactly representable in the IEEE 754 format. With our current rounding scheme, the correct return value should have been 9007199254740996. However, the last .0 portion of the input was forcing the parser to incorrectly round the result and return 9007199254740998.



SignalR – Nullable annotations

The ASP.NET Core SignalR Client package has been annotated for nullability. This means that the C# compiler will provide appropriate feedback, when you enable nullability, based on your handling of nulls in SignalR APIs. The SignalR server has already been updated for nullability in 5.0, but a few modifications were made in 6.0. You can track ASP.NET Core support for nullable annotations at dotnet/aspnetcore #27389.

Nullable annotations were a big focus of the .NET Core 3.x and .NET 5 releases. All of the .NET libraries (AKA “base class libraries”) were annotated as part of those releases. The System.Device.Gpio package was also annotated as part of the .NET 5 release.

You need to add <Nullable>enable</Nullable> in your project file to use the nullable annotations.


The following improvements have been made in (or related to) the .NET runtime.

Framework Assemblies are compiled with Crossgen2

Update: This change (compiling more assemblies with crossgen2) didn’t make it into Preview 2, but will be part of Preview 3.

All of the .NET libraries are now compiled with crossgen 2, across all supported operating systems and architectures. This includes all libraries in the Microsoft.NETCore.App directory, but not the other frameworks, such as ASP.NET or Windows Desktop. Those frameworks will be transitioned to crossgen 2 in Previews 3 and/or 4.

Crossgen 2 itself isn’t intended to improve performance. As I said in the preview 1 post, the purpose of Crossgen 2 is to enable new performance features like PGO. That said, Crossgen 2 has delivered modest size-on-disk improvements based on some targeted size optimizations, as you can see in the following comparison. Main point is that moving to Crossgen 2 does not incur any up-front regressions. It is effectively neutral, as promised.

Size [MB] FullName
--------- --------
64.22     C:Program FilesdotnetsharedMicrosoft.NETCore.App5.0.3
63.31     C:Program FilesdotnetsharedMicrosoft.NETCore.App6.0.0-preview.1.21102.12
63.00     C:Program FilesdotnetsharedMicrosoft.NETCore.App6.0.0-preview.2.21118.6

Profile guided optimization

Profile guided optimization enables us to generate code that is optimal based on a variety of characteristics. We are building both static and dynamic PGO variations.

The following improvements have been made in Preview 2:

JIT improvements

The following improvements were made to optimize the code generated by the JIT.

The first improvement is the latest result of a project to stabilize performance measurements. You can read recent analyses (January 26, 2021; February 3, 2021) that provide an in-depth explanation of our progress.

The second improvement is specific to Arm64. We continue to improve the performance of the code that the JIT generates for Arm64, in collaboration with Arm engineers.


We’re back to the regular monthly previews, with .NET 6. Please give .NET 6 Preview 2 a spin in your environment, in a container, a virtual machine or on a test machine. We want your feedback to help us improve these new features before we release the final version in November. We expect that the majority of the release should be done by July; we’ll focus on quality after that. That gives you a sense of the windows we have for feedback. The earlier you can give feedback, the better.

You can expect to see more in .NET 6 for mobile and Blazor Desktop in subsequent previews. We’re still in the process of building those features.


Discussion is closed. Login to edit/delete existing comments.

  • Kevin Weir 0

    Good stuff Richard. Especially happy about seeing ReferenceHandler.IgnoreCycles which will accelerate adoption of System.Text.Json for WEB API’s.

    Also, finally unifying all he different flavors of .NET going forward will be huge.

    • Richard LanderMicrosoft employee 0

      Yes. The team is doing a great job adding a lot of valuable features. It’s a pleasure to get to write about them.

      • Kevin Weir 0

        Now just waiting for a world class WYSIWYG IDE to develop UWP/WinUI3 applications. 🙂

        If Microsoft wants to reinvigorate the Windows desktop there is no better place to start. Getting mired in endless XAML hierarchies in a text editor is really holding things back in my humble opinion.

        • Miguel RamosMicrosoft employee 0

          Thanks for your feedback. The XAML designer for WinUI 3 is in the backlog, and unfortunately it won’t be part of the v1 that will be shipped in Fall 2021. So there is no commitment (no ETA) for adding designer support yet.

          • Kevin Weir 0

            Great to hear that its at least in the backlog. If the IDE is well executed I think you’ll see a measurable uptake in desktop development.

          • Juri Ryazanov 0

            Designer Support for MAUI is really important. Please implement it.

          • saint4eva 0

            Any plans for writing Windows UI using C#? Very important for those who do favour writing UI in code (e.g. C#) to xaml.

          • Daniel Steiner 0

            same desaster as with Winforms designer for .NET Core 3.x

          • Stevie White 0

            Hi Miguel, when you say “XAML Designer”, do you really mean just the ability to write XAML with intellisense or are you talking about a new type of WYSIWYG portion of the XAML creation workflow? The WYSIWYG portion of the XAML designer has always been a… (I really do not know how else to describe this) tortious experience to use and I personally always turn it off. From what I have seen, the only designers MS ever did right were the ones for Visual Basic and Windows Forms. I am not saying this to insult you, but it is a general concern since there are a lot of developers who still prefer using WYSIWYG due to a range of factors.

            I really hope you can take this opportunity to get the drag and drop experience of the XAML designer right. While I am more than fine with doing XAML by hand since I first started with ol’ HTML, I find a lot of developers not wanting to leave behind Windows Forms and its kin because of the poor user experience found with the drag and drop portion of the XAML designer.

  • AlseinX 0

    So, it is Windows this time, that is excluded from the MAUI single project multitargeting support, without any annotation about why.

    From the beginning of the MAUI’s announcement, Linux support was killed just because Xamarin does not support Linux yet, and it is not even planned for official support in the future. BTW, as for production use, the so-called “community support” equals to “nope”.
    And Xamarin.Forms support for Windows was announced several years ago but up to today there isn’t any production-ready release about Xamarin.Forms on Windows. There was only a technical UWP integration.
    Now that .NET 6 is coming, it could be a dangerous signal, which is: If something disappears without annotation, it must have been killed, just like Native AOT, which was previously announced as CoreRT as a part of .NET Core 1.0 and has been being soundlessly killed again and again since 2016, and still not mentioned in 2021.

      • AlseinX 0

        Will this be delayed? The last one like this was Blazor WebAssembly, which did not join the main .NET Core versioning and preview, and was left behind while Blazor Server has made it into .NET Core 3.1.

        • saint4eva 0

          Are you using Blazor now that it has been included? Kindly note that the team is building and adding features incrementally, as they are rebooting/ evolving Xamarin.Form. As for some people, we can’t wait to see C# MVU UI support.

    • Emmanuel Adebiyi 0

      CoreRT is alive and well. Also, it is still being actively maintained. It’s not just the top issue on the list at the moment. The repo was moved somewhere into runtimelabs I think

      • AlseinX 0

        Indeed it is in the runtimelab repo, which means it is still an experimental project while other features are ready for preview.

    • Ruslan Yakauleu 0

      Yeah. It is very interesting why Linux support removed from Xamarin

      • saint4eva 0

        Kindly note that flutter just added desktop feature in version 2. And moreover, it is still in preview. So, the team will keep adding features and support as they go forward.

  • Wilfrans Millán 0

    Awesome news!
    Thank you all for your hard work.

  • Shreyamsh Kamate 0

    Awesome! Can’t wait for it.

  • Tony Henrique 0

    .NET 6 looks promissing!!!
    Lots of great features! I will download this preview right now!

  • Emmanuel Adebiyi 0

    Great work by all the teams working to pull this together. Awesome stuff. Thanks Richard for the well articulated brief.

  • 彭伟 0

    Java interoperability will be available on all platforms.
    Objective-C and Swift interoperability will be supported on multiple operating systems.

    Have any plan?

  • x x 0

    Speaking about the performance, have you seen the series of tweets by Bartosz Adamczewski?

    He’s conducted so many tests showing that the optimizer and jitter are producing very low quality machine code in a lot of scenarios.

    • x x 0

      Please do review Bartosz’s screenshots also here as he points out serious deficiencies in optimizer and jitter –
      In one place you’ll find all actionable issues that hugely impact .NET performance.

      • Andy AyersMicrosoft employee 0

        Yes, we have seen these.

        Some of them have inspired changes in the jit that will appear in 6.0, and others have helped shape the work we plan to do in the future.

  • PAthum Bandara Premaratne 0

    What about .Net FX? When can we have new lang features and compiler features for windows? Rewriting several enterprise applications is not an option. And we cannot kill them either like you do.

    • Steve 0

      Although .NET FX won’t receive feature updates, you can always opt-in new language version via specifying LangVersion and use those features don’t require CLR changes:

  • Reinhard Moosauer 0

    One question: The preview 2 is announced as “tested with Visual Studio 16.9”, but for me it does not work:
    “The current .NET SDK does not support targeting .NET 6.0.” with 16.9.1

    • Huo Yaoyuan 0

      You should enable “Use preview version of .NET SDK” in your VS settings, or specify 6.0 preview version in global.json.

      • Reinhard Moosauer 0

        Ah, thanks!
        I like this best: global.json

Feedback usabilla icon