Announcing .NET 5 Preview 1

Scott Hunter [MSFT]


At the end of last year, we shipped .NET Core 3.0 and 3.1. These versions added the desktop app models Windows Forms (WinForms) and WPF, ASP.NET Blazor for building single page applications and gRPC for cross-platform, contract-based messaging. We also added templates for building services, rich generation of client code for talking to gRPC, REST API services, and a lot more. We’re excited to see that .NET Core 3 has become the fastest adopted version of .NET ever and we’ve gained another million more users in just the last year.

We also communicated with these releases that this would conclude the porting of the app models from .NET Framework. With .NET Core 3, we have ported all of the most used app models as well as introduced newer cross- platform frameworks to replace the ones we did not port.

As we look forward to the next major release, .NET 5, we will continue to unify .NET into a single platform by including our .NET mobile device app model (Xamarin) in .NET 5. .NET 5 will include ASP.NET Core, Entity Framework Core, WinForms, WPF, Xamarin and ML.NET. For the first time, the entire platform will use a unified BCL (Base Class Libraries) for all the app models. Having a version 5 that is higher than both .NET Core and .NET Framework also makes it clear that .NET 5 is the future of .NET, which is a single unified platform for building any type of application.

We have said this many times, but we will reiterate again; .NET Core and then .NET 5 is the .NET you should build all your NEW applications with. .NET Framework will remain supported as long as Windows itself is supported. We will continue to provide security and bug fixes and keep the networking and crypto API’s up to date. It will remain safe and supported to keep your older applications on .NET Framework.

Install .NET 5.0 Preview 1

Today we are releasing the first preview of .NET 5, which is scheduled to GA (General Availability) later this year in November.

See ASP.NET Core updates in .NET 5 Preview 1 to learn about today’s ASP.NET Core release.

Preview 1 includes support for Windows ARM64 for the first time. Today’s release includes the .NET Core runtime. We expect Preview 2 to include the SDK (ASP.NET Core but not WPF or Windows Forms). A later preview will include WPF and Windows Forms. Support for Windows ARM64 will also be back-ported to .NET Core 3.1. We will share more information on that with the Preview 2 post.

Updating existing projects

You can update existing projects by updating your target framework, as follows:


High-level goals for .NET 5

Let me highlight some of the high-level goals for .NET 5:

  • Unified .NET SDK experience:
    • Single BCL (Base Class Library) across all .NET 5 applications. Today Xamarin applications use the Mono BCL but will move to use the.NET Core BCL, improving compatibility across our application models.
    • Mobile development (Xamarin) is integrated into .NET 5. This means the .NET SDK will support mobile. For example, you can use “dotnet new XamarinForms” to create a mobile application.
  • Native Applications supporting multiple platforms: Single Device project that supports an application that can work across multiple devices for example Window Desktop, Microsoft Duo (Android), and iOS using the native controls supported on those platforms.
  • Web Applications supporting multiple platforms: Single Blazor project that supports an application that can work in browsers, on mobile devices and as a native desktop application (Windows 10x for example)
  • Cloud Native Applications: High performance, single file (.exe) <50MB microservices and support for building multiple project (API, web front ends, containers) both locally and in the cloud.
  • Continuous Improvements, such as: faster algorithms in the BCL, better support for containers in the runtime, support for HTTP3.

Today’s first preview does not contain all the work to support these high-level goals yet, but we will continue to announce more capabilities and features in future previews.

Improvements in Preview 1

The following improvements are in Preview 1:

Regular expression performance improvements

We’ve invested in significant improvements to the Regex engine. On many of the expressions we’ve tried, these improvements routinely result in throughput improvements of 3-6x, and in some cases, much more. We have a blog post coming shortly that will describe these improvements in much more detail.

Code quality improvements in RyuJIT

Every release includes a set of performance improvements to the code that the JIT generates. We refer to these type of improvements as “CQ” or code quality. In most cases, these improvements also apply to the code generated for ready-to-run images.

The following improvements are in preview 1:

Assembly load diagnostics added to event pipe

We have added assembly load information to event pipe. This improvement is the start of making similar diagnostics functionality available as is part of .NET Framework with the Fusion Log Viewer. You can now use dotnet-trace to collect this information, using the following command:

dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:4:4 --process-id [process ID]

The workflow is described in Trace Assembly Loading with Event Pipe. You can see assembly loading information for a simple test app.

Image trace assemblies loads

Event pipe profiler APIs

Event pipe is a new subsystem and API that we added in .NET Core 2.2 to make it possible to perform performance and other diagnostic investigations on any operating system. In .NET 5.0, the event pipe has been extended to enable profilers to write event pipe events. This scenario is critical for instrumenting profilers that previously relied on ETW to monitor application behavior and performance.

GitHub repo consolidation

As part of the .NET 5 release, we reduced the number of GitHub repos we use to build and package .NET. Repo boundaries have a significant impact on many aspects of a project, including builds and issue management. With .NET Core 1.0, we had over 100 repos across ASP.NET, EF and .NET Core. With this latest release, we can now count the primary repos on one hand. We also moved nearly all repos to the dotnet org.

Check out the new, consolidated, repos:


We hope that you are excited about the work that is happening with .NET 5! The best way to prepare for .NET 5 is to move all of our .NET Core applications to 3.1- we will make the transition from .NET Core 3.1 to .NET 5 as painless as possible. And if you are still building applications on .NET Framework, please feel safe leaving those applications on .NET Framework but think of using .NET Core 3.1 for all your new applications. There are lots of exciting things coming to .NET!


Leave a comment

  • Avatar
    Diego de Felice

    About .net Framework, this “We will continue to provide security and bug fixes and keep the networking and crypto API’s up to date.” is what we wanted to hear, since was one of the biggest concern. Thanks.

      • Avatar
        Jack Bond

        Really Scott? That’s awesome. I’ve got to tell you Microsoft’s ongoing support of Silverlight has been AMAZING.

        Oh, oh, and the recent addition of .NetStandard 2.1 support to .NET Framework 4.8, TRULY TRULY AMAZING.

        Please explain to us how .NetStandard even makes sense as a compilation target anymore, when Microsoft…


        Yah, that’s great “support”. For the record, I don’t even care, I’ve wholly adopted Core, but please, stop blowing smoke up people’s ****** about supporting .NET Framework. It’s just pathetic at this point.

      • Avatar
        Jon Miller

        Yes, you can “think” about new apps. Since Web Forms isn’t moved forward and there isn’t really a replacement. Blazor isn’t there yet iMHO. You ported Windows Forms and WPF. Yet Web Forms was an impossible task. The truth is, you could have done Web Forms, but, chose not to, in order to push the newer less functional stack.

      • Avatar

        Well our company is so pissed at MS for dropping new features for .NET Framework .. for dropping .NET Framework. We have huge .NET Framework applications we can’t port to Core and using Core in future projects, just mean that we can’t mix them – can’t even use Standard 2.1+ since it is not compatible with .NET Framework. …. sigh!!! What a mess!!!

    • Avatar
      Richard LanderMicrosoft logo

      It is possible that Unity may adopt .NET 5 (or a later version) for their tools stack. I am doubtful they will use it for their apps since they target a larger set of platforms than we do. That is why they have focused on their IL2CPP project. We talk with Unity folks fairly regularly, so we’ll be happy to offer any help they ask for.

  • Avatar
    Chris Coble

    “Web Applications supporting multiple platforms: Single Blazor project that supports an”
    “application that can work in browsers, on mobile devices and as a native desktop application”

    How is this working? Is .Net 5 or Xamarin getting the “Blazor Native” rendering stack built in?

      • Rod Macdonald
        Rod Macdonald

        If I might suggest, MS need to get back to ‘.NET basics’ and re-deliver on the Y2000 promise of .NET. There are signs that MS recognise that all the different app ‘silos’ have diametrically moved the fundamentals apart and that it’s time to bring things back together. None the less, your comment concerns me. Blazor is/was initially supposed to be aimed at client side. I don’t really want to be scratching my head if I want to build a client app – do I build a Xamarin app or a Blazor app – should it be mobile, should it be desktop? Should it be for Windows, Android or iOS? I just want to build an app. If we really need Windows as an OS (i.e. something beyond a window, container or browser), a common UI stack where XAML is a super set of HTML should suffice, and I just extend my code for the situation.

        So the fundamental issue is that we need a cross platform UI stack atop .NET 5. I haven’t read anything about .NET 5 that addresses that concern.

    • Avatar
      Immo Landwerth Microsoft logo

      .NET is about choice. Today, we have a very strong offering to target the individual platforms with no loss in fidelity, i.e. full access to the native APIs. With Xamarin Forms you can already write cross-platform applications with high amounts of code reuse; you can expect that we’ll be extending this model in the future. However, I doubt that we’ll ever provide a cross-platform only solution. Sometimes, you need access to a platform-specific API. My hope is that our tooling never gets in the way of doing that while also making it crystal clear when you do so, so that you’re not accidentally becoming platform dependent.

      • Avatar
        melon NG

        Aha. Thanks for replying to me. I conjecture .Net 5 will be a cross-platform framework base on the programming language of Blazor for Microsoft has paid much on it. And also, it seems we can use Blazor to code Xamarin in the future for Microsoft published an experimental mobile Blazor binding template before long. I think the Blazor binding template will also available in WPF in the future. Well, all just is a conjecture. All of them are a secret until Microsoft publishes all about it.

  • Avatar
    Niall Ginsbourg

    Lot of folks on Twitter asking – can you please clarify the high-level goal :
    “Native Applications supporting multiple platforms: Single Device project that supports an application that can work across multiple devices for example Window Desktop, Microsoft Duo (Android), and iOS using the native controls supported on those platforms.”

    Are you talking about Xamarin (Forms?) + .NET 5? UWP + .NET 5? or is there something brand new on the horizon?

    • Phillip Carter
      Phillip CarterMicrosoft logo

      At this time, there aren’t plans to move Visual Studio to .NET 5. Visual Studio is an immense codebase with many components that take a hard dependency on .NET Framework APIs that aren’t compatible with .NET Core. A .NET 5 version of Visual Studio would force a lot of components (and extensions!) to be unsupported, leaving a lot of customers without the tools that they know and love.

      That being said, in VS 2019 there was an effort to move components to .NET Standard 2.0 and/or .NET Framework 4.7 so that we could begin to do things like share some components between Visual Studio and Visual Studio for Mac. There may be future work more aligned with similar goals.

  • 남정현

    Great news! I’m happy hear about that. ☺️

    I have a question about the high level goals about compilation.

    Cloud Native Applications: High performance, single file (.exe) <50MB microservices and support for building multiple project (API, web front ends, containers) both locally and in the cloud.

    Does this paragraph points out to CoreRT?

  • Avatar
    Piercarlo Schiavo - BIsolution

    Hello Scott,
    I updated my project (Blazor Client + Web Api Server Side) to Core 5.0.
    But I have following problem with DataContext.cs:

    public DataContext(DbContextOptions<DataContext> options) : base(options)

    On instancing on above constructor point I get the following error: cannot load “Microsoft.Bcl.AsyncInterfaces”

    I tried to install the package but it is following with a lot of errors more.

    I needed to downgrade the all to work.

    Some suggestion ?

    Thank you

    • Avatar
      Jos Krause

      Hi Piercarlo,

      From what I understood is that IAsyncEnumerable is contained within the ‘Microsoft.Bcl.AsyncInterfaces’ package for .NET Standard 2.0 scenarios, but is included in ‘System.Runtime’ starting with .NET Standard 2.1. Is it possbile that some of your current project dependencies are targetting a lower framework thus pulling back in this dependency? Perhaps some packages require an update so they can target the newer framework? (#thoughts-out-loud)

      • Avatar
        Piercarlo Schiavo - BIsolution

        Dear Jos,
        I investigated on your suggestion but I think the problem is in somewhere else:

        I updated to Framework 5.0 as follow:


        I updated one per one the all existing packages and all packages are working fine except for following packages:


        Last working version: 3.1.3

        The project is a Blazor Webassembly + WebApi Servers Side

        The problem coming on EntityFramewok and related packages.

        Some suggestions?

  • Avatar
    Stuart Ballard

    Presuming there’s still no plan to support ASP.NET Web Forms on anything other than .NET Framework, have you considered making the Web Forms codebase open source so that third party developers could try porting it? I’m maintaining a large Web Forms application, and while it’s nice to know that there will be continued security and bugfix support, it’s frustrating to be locked out of all new features, especially now that new versions of the C# language itself are tied to the new platform versions as well!

    • Avatar
      Richard LanderMicrosoft logo

      Correct. ASP.NET Web Forms will not be supported on .NET 5+. We actually tried this a few years ago. It became obvious that it was going to be a challenging project. This is primarily because Web Forms depends on a bunch of APIs not in .NET 5, and to a large degree that we cannot add back. Many APIs were removed from .NET Core because they created really bad dependencies that turned the product back into a monolith. In the case of instance methods, they can be added back as extension methods. Static methods, properties and interfaces cannot be.

      I believe this is the source:

      • Avatar
        Stuart Ballard

        Last time I’d searched I wasn’t able to find the Web Forms code in the reference source – the github history seems to suggest those files were missing originally and only got added to the repo in August. Glad to see they’re available now!

      • Avatar
        Jon Miller

        One other thing worth noting. There are often breaking changes between version. You could have moved Web Forms forward and left out the functionality that wasn’t available on .NET Core. It would have been better than dropping it altogether. Instead, you would rather force developers onto a less functional stack. Blazor should include UI controls by default. Things like a grid control that supports sorting, filtering, paging, inline editing, etc. Application developers shouldn’t have to roll their own on that stuff. It should be there out of the box. Things should be getting easier. It’s been 15 years. MVC was a step backwards. Web development has not improved for at least that long. Things are getting worse, not better. Also, had Microsoft actually developed controls like a grid component, maybe it would uncover issues in the underlying design that need to be addressed. The for-for pay Blazor controls that I’ve seen aren’t as good as they are in Web Forms. And also, in this day and age, that should just be built into the platform.

  • Avatar
    Vitaliy Korney

    Hello Scott! Great news, but I want to complain regarding xamarin team. Miguel de Icaza told a year ago on twitter that Catalyst feature will be implemented and now managers at xamarin denies that they commited to implement it and this feature is not only implemented to comply to ios 13, but nobody at xamarin even cares about it. Miguel’s tweet was hidden from public recently. It’s an obvious feature compared to surface duo android feature. Developers want to publish their ipad apps to mac appstore. Seems like you have poor management at xamarin since they do not respond to people and say in twitter that we don’t need this feature saying they collect feedback. React native already implemented this feature. Can you make them at least to provide answer at github regarding plans or whatever? How come that they do features to support surface duo but completely deny catalyst feature?
    Should we demand xamarin to make them comply to xcode 11?

    • Avatar
      David OrtinauMicrosoft logo

      Hi Vitaliy,

      We absolutely care and would love to deliver support for Catalyst at the right time. That is determined by understanding value to customers and balancing that with other impactful priorities. We continue to listen and observe to determine when that time might be. At this time we are not working on enabling Catalyst support. I would be happy to discuss this more in depth with you and learn about your business needs.

      The best path to macOS for .NET developers today is using Xamarin.Mac and Xamarin.Forms to maximize code share.

      We support Surface Duo and Surface Neo because they are amazing, category changing first-party devices! Not only that, but they run Android and Windows which are already supported in .NET. In fact, Xamarin.Forms was able to support them without making any core changes. What better value than enabling .NET developers to target Microsoft’s flagship devices!

      • Avatar
        Vitaliy Korney

        Hi, David! I don’t believe in marketing only time will show if those devices are competitive or not. I don’t feel excitement when another android vendor appears especially when I have to write additional code to support it. Catalyst was exciting to developers.
        I’ve made a research and it will take half a year to port my app from ios to xamarin.mac. while it may look the same it’s a completely different platform, they have similar controls, similar classes, similar events, but even enums are different. Listening means understanding what customers wants. I don’t want to spend half a year doing monkey job porting app to another platform I would prefer spending few weeks making sure my app will work fine both on ipad and mac. I’m pretty sure I won’t be able to implement my app using xamarin forms. Anyway it will take another half a year. What you suggest is to invest in another half a year of development. And I’m just one customer. You offer spending money to all customers on development, because you have different priorities. Maybe it’s another mistake made by me to invest in dead platform like silverlight, winphone, windows store app. But I hope it was not a mistake. A friend of mine has diagramming app on ipad (grapholite) and he also don’t want to spend money on mac development, since it’s a lot of work with ui. He does not like Xamarin Studio and was happy when Catalyst was announced 2 years ago. I have database app for uwp, android and ios. And I keep getting requests of a mac app.

      • Avatar
        Vitaliy Korney

        This is what your people say at github: “it’s the top request from the new iOS 13 features, so it will be prioritized accordingly.” It is completely different from what you say here. Maybe you take too much responsibility by freezing this feature, don’t you? Seems like your developers’ point of view resonates with my point of view and with others who want this feature. I’m writing here since I haven’t lost hope for this feature yet and I got your point of view, which contradicts with me. I wanted to escalate this problem since today our dialog is not constructive at all. You don’t make it and wait. What should happen for this feature to be planned in the next iteration, who make decisions? Best time to implement this feature is 3 month ago. Maybe you should hire developers if you have deficit of the workforce.

        • Avatar

          Sorry Vitaliy, but you didn’t use email with your follow up comments to David as requested. So instead of your pleas being discarded and ignored via email, they will be subsequently discarded and ignored here instead.

  • Avatar
    Nuryani Zahira

    I have not got the following statement:

    Native Applications supporting multiple platforms: Single Device project that supports an application that can work across multiple devices for example Window Desktop, Microsoft Duo (Android), and iOS using the native controls supported on those platforms.

    What is difference between Xamarin.Forms solution ?
    Does it mean that C# will compile to other platform specific formats aka Java byte code, native instructions and so on ?

      • Avatar
        Charles Roddie

        Some oversight of Xamarin.Forms would make sense. Their approach maximizes bugs, via doing absolutely everything once per platform, taking on more and more new features. We’ve ended up only using the most basic elements because they have the greatest chance to work, but they are still somewhat buggy and bugs are created for core components as fast as they are fixed. I belive there is a need for a Xamarin.Forms.Core, a maintainable core library that works, with everything else in separate repos (Xamarin.Forms.XAML, Xamarin.Forms.CSS, Xamarin.Forms.Shell, etc.).

  • Roman Blinkov
    Roman Blinkov

    How I can install template for Xamarin?

    dotnet new XamarinForms

    does not work for me.

    C:\Projects\NET5>dotnet –version

    C:\Projects\NET5>dotnet new XamarinForms
    Couldn’t find an installed template that matches the input, searching online for one that does…
    Usage: new [options]

    -h, –help Displays help for this command.
    -l, –list Lists templates containing the specified name. If no name is specified, lists all templates.
    -n, –name The name for the output being created. If no name is specified, the name of the current directory is used.
    -o, –output Location to place the generated output.
    -i, –install Installs a source or a template pack.
    -u, –uninstall Uninstalls a source or a template pack.
    –nuget-source Specifies a NuGet source to use during install.
    –type Filters templates based on available types. Predefined values are “project”, “item” or “other”.
    –dry-run Displays a summary of what would happen if the given command line were run if it would result in a template creation.
    –force Forces content to be generated even if it would change existing files.
    -lang, –language Filters templates based on language and specifies the language of the template to create.
    –update-check Check the currently installed template packs for updates.
    –update-apply Check the currently installed template packs for update, and install the updates.

    No templates matched the input template name: XamarinForms.

  • Avatar

    Mention of UWP is conspicuously absent from this announcement. A couple years ago those using WPF (myself included) had to look high and low for WPF support. Microsoft was endorsing UWP as the future; were we foolish to listen and make the plunge?

    Now it’s becoming ever harder to find anyone at Microsoft make mention of UWP, and all the online docs are starting to have WinUI as the placeholder for UWP (e.g. So what’s the real story with UWP?

    Making mention of gRPC is particularly painful to see if you’re a UWP developer because Microsoft has yet to invest the effort required to make it work with UWP even though the required changes to support UWP are trivial.

    You can imagine why it might be hard to get excited about these announcements, given the inconsistency in tech churn. May we please get a definitive statement about the UWP roadmap or whether there is one.

  • Avatar
    Irina Pykhova

    what do you mean by “A later preview will include WPF and Windows Forms”? We tried both WPF and WF apps, looks like almost everything what worked in .Net Core 3.1 also works in .Net 5 preview. Do you have some specific plan for changes in WF and WPF?

  • Avatar

    Are Microsoft in a position yet to talk about the future of .Net Standard? With a single framework (.Net 5) I could see the need for this to go away, but will Blazor client apps be running a cut-down version…..will .NetStandard be needed to bridge that gap?

  • Avatar
    debadutta pahadsing

    Great Work by Scott & Team.

    We have been using .net for our enterprise applications for almost 15 years.
    One obstacle we are facing in adopting .net core is the lack of report designer/ viewer tools.
    Any plan to include the same in .net core & vs 2019 or we need to turn to 3rd party vendors for the same?


  • Todd Fulton
    Todd Fulton

    Wow, this sounds like a big leap forward. As a linux user I’ve been enjoying getting into C# and F#. I know we’ve had Mono for a long time, but the name just reminds me of streptococcus, so I never touched it. I’ll say as a C++/python guy it’s nice having a strongly typed language with proper reflection and dynamic features when you want them, while not having to worry about (smart) pointers. C# feels like the best of C++ and python. My only wish is that we had free functions. Just saying, the C# and F# languages are really well designed imho, but, it would be nice to compile down to binary ahead of time, another user mentioned this previously in this same comments section, something similar to go.

    Feels like a good time to be picking up .Net. Super stoked about F# 5.

    Any support in VS Code for .Net 5? Maybe insiders?

  • Avatar
    Jerome Boyer

    What is the impact on SQLCLR?
    Currently there is a semi disconnect between various SQL version and the .NET being supported. SQL 2016-2019 expect. .NET 4.5
    Will code in .NET 5.0 be supported in these SQL versions?

  • Avatar
    Renato Katalenić


    we just started building our app in .NET Core 3.1.
    What will happen after D day “”2022-12-03″” and support for .NET Core 3.1 is over?
    Will .NET Core still be alive and running apps?
    Will it have same scenario as .NET Framework or we will be forced to migrate to .NET 5 or 6 or 7..?

    Thx 🙂

    • Avatar
      Carl in 't Veld

      The new lifecycle policies for .NET Core and .NET onwards enable Microsoft to move fast without the burden of keeping up the support for all former versions and/or downwards compatibility. So yes, you should preferably migrate to .NET 5 before the end-of-life of .NET Core 3.1.

  • Avatar
    Andrei P.

    We have .NET Framework wrapper for our native C++ library for years. It uses SWIG. The library itself exists for Windows and Linux, but the existing wrapper obviously works on Windows only. We want to port it to Linux and .NET Core. I used .NET Core and made the wrapper fully working on Windows, but on Linux it works only partially. So I want to debug the native library on Linux, starting from .NET Core app and into C++ code. Is this going to be addressed?

  • Ananthapadmanabhan Subramani
    Ananthapadmanabhan Subramani

    Trying to simply this for my understanding..

    If I have .NET core 3.1, when and why would I need .NET 5?

    If I run my apps in containers… and my base image = Linux (e.g. Alpine 3.x) which would would be more suited.

    Does .NET 5 include .net Core 3.1 or does .net 5 require .net core to be installed as a pre-requisite?

    Blazor + .net Core + webAssembly… where does .net 5 fit in here?