ASP.NET Core updates in .NET Core 3.1

Sourabh Shirhatti [MSFT]

ASP.NET Core updates in .NET Core 3.1

.NET Core 3.1 is now available and is ready for production use! .NET Core 3.1 is a Long Term Support (LTS) release.

Here’s what’s new in this release for ASP.NET Core:

  • Partial class support for Razor components
  • Pass parameters to top-level components
  • New component tag helper
  • Prevent default actions for events in Blazor apps
  • Stop event propagation in Blazor apps
  • Detailed errors during Blazor app development
  • Support for shared queues in HttpSysServer
  • Breaking changes for SameSite cookies

You can find all the details about these new features in the What’s new in ASP.NET Core 3.1 topic.

See the release notes for additional details and known issues.

Get started

To get started with ASP.NET Core in .NET Core 3.1 install the .NET Core 3.1 SDK.

If you’re on Windows using Visual Studio, install Visual Studio 2019 16.4. Installing Visual Studio 2019 16.4 will also install .NET Core 3.1, so you don’t need to separately install it.

Upgrade an existing project

To upgrade an existing ASP.NET Core app to .NET Core 3.1, follow the migrations steps in the ASP.NET Core docs.

See the full list of breaking changes in ASP.NET Core 3.1.

To upgrade an existing ASP.NET Core 3.1 Preview 3 project to 3.1:

  • Update all Microsoft.AspNetCore.* and Microsoft.Extensions.* package references to 3.1.0

That’s it! You should now be all set to use .NET Core 3.1!

Blazor WebAssembly update

Alongside this .NET Core 3.1 release, we’ve also released a Blazor WebAssembly update. Blazor WebAssembly is still in preview and is not part of the .NET Core 3.1 release. Blazor WebAssembly will ship as a stable release at a future date.

To install the latest Blazor WebAssembly template run the following command:

dotnet new -i Microsoft.AspNetCore.Blazor.Templates::3.1.0-preview4.19579.2

This release of Blazor WebAssembly includes a number of new features and improvements:

  • .NET Standard 2.1 support
  • Support for static assets in when publishing
  • iOS 13 support
  • Better linker errors
  • Attach to process debugging from Visual Studio

.NET Standard 2.1 support

Blazor WebAssembly apps now target .NET Standard 2.1 by default. Using .NET Standard 2.1 libraries from a Blazor WebAssembly app is now supported within the limits of the browser security sandbox.

Support for static assets in libraries when publishing

Standalone Blazor WebAssembly apps now support static assets from Razor class libraries both during development and when publishing. This applies to both standalone Blazor WebAssembly apps and ASP.NET Core hosted apps. Static assets are consumed from referenced libraries using the path prefix: _content/{LIBRARY NAME}/.

iOS 13 support

Blazor WebAssembly apps now work from iOS 13 based devices. The .NET IL interpreter now uses a non-recursive implementation to prevent exceeding the size of the stack on these devices.

Better linker errors

The IL linker is now integrated with Blazor WebAssembly projects such that linker errors are surfaced as build errors.

Attach to process debugging from Visual Studio

You can now debug Blazor WebAssembly apps from Visual Studio by attaching to the browser process. Currently this experience is very manual. In a future update, we expect to enable Visual Studio to handle all of the necessary wire-up to debug a Blazor WebAssembly app when you hit F5. Also, various features of the debugging experience (like viewing locals) are not yet enabled. This is something we will be working on over the next few months.

To debug a running Blazor WebAssembly app from Visual Studio:

  1. Run the app without debugging (Ctrl-F5 instead of F5)
  2. Open the Debug properties of the app and copy the HTTP app URL
  3. Browse to the HTTP address (not the HTTPS address) of the app using a Chromium based browser (Edge Beta or Chrome).
  4. With the browser in focus, press Shift-Alt-D and then follow the instructions to open a browser with remote debugging enabled
  5. Close all other browser instances
  6. In Visual Studio, select Debug > Attach to Process.
  7. For the Connection type, select Chrome devtools protocol websocket (no authentication).
  8. For the Connection target, paste in the HTTP address (not the HTTPS address) of the app and press Enter (don’t click “Find” – that does something else).
  9. Select the browser process you want to debug and select Attach
  10. In the Select Code Type dialog, select the code type for the specific browser you are attaching to (Edge or Chrome) and then select OK
  11. Set a break point in your app (for example, in the IncrementCount method in the Counter component) and then use that part of the app to hit the breakpoint.

In a later release, this process will become automated inside Visual Studio and Visual Studio Code so you can launch and attach the debugger with a single click or keystroke. Then you will no longer need to go through this detailed attachment process manually.

Give feedback

We hope you enjoy this release of ASP.NET Core in .NET Core 3.1! We are eager to hear about your experiences with this latest .NET Core release. Let us know what you think by filing issues on GitHub.

Thanks for trying out ASP.NET Core!


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

  • Marcel 0

    When will .NET Core 3.0 be able to run on Azure?
    It’s been 2+ months since the “release” in September and we still can’t deploy our .NET Core 3.0 code to Azure due to the latest deployment SDK on Azure STILL being .NET Core 2.2.

    Can somebody please light a fire under this?

    • Nitesh Shrestha 0

      Is this what you meant?

    • Brady GasterMicrosoft employee 0

      The App Service team is actively working on getting the 3.1 runtime and SDK installed worldwide. Today, 3.1 and 3.0 runtimes are everywhere, and the SDK is coming next. The App Service team is trying to get the new SDK installed before the end-of-calendar-year (this calendar year, to be precise).

  • Rene Elizondo 1

    I am sure that you guys are already working on this but just in case… the “3.1.0-preview4.19579.2” runtime is not yet available in Azure through the Extensions option. Is not a deal breaker but it is really convenient to have it available.

    • Daniel RothMicrosoft employee 0

      Hi Rene,

      There isn’t a 3.1.0-preview4.19579.2 runtime release for .NET Core. .NET Core 3.1 is now a stable release, so you want 3.1.0. That 3.1.0-preview4.19579.2 version number only applies to Blazor WebAssembly, which is still in preview.

      I hope this helps!

      Daniel Roth

  • Andriy Savin 0

    Hi, in the “Upgrade” section you mention .Net 3.0 multiple times as the upgrade target (“ASP.NET Core app to .NET Core 3.0”), while I believe it should be 3.1.

    • Daniel RothMicrosoft employee 0

      Thanks for bringing this to our attention. This should be fixed now.

  • Gauthier M. 0

    Blazor VS Debuging don’t work.

    Step 1 to 9 are ok. But just after I attach the chrome process to VS, I show many JS file appear in Solution Explorer then desappear and the process detach itself…
    So I can’t place my breakpoints or doing anything…

    • Тимофей Буланкин 0

      Debugging blazor webAssembly is hell at this moment. I wait when they give the possibility of debug through the vs.

    • Daniel RothMicrosoft employee 0

      Hi Gauthier,

      I’m sorry this isn’t working for you! The debugging experience for Blazor WebAssembly apps in Visual Studio is pretty rough right now, so it’s very likely you’re hitting a bug. Could you please open an issue on GitHub with details steps to reproduce the issue so that we can take a look?:


      Daniel Roth

  • Hugo Ferreira 0

    For when Multiple ASP.NET Core Applications In Process per Application Pool ?

  • News Tech Guru 0

    Hi, in the “Upgrade” section you mention .Net 3.0 multiple times as the upgrade target (“ASP.NET Core app to .NET Core 3.0”), while I believe it should be 3.1.

    check this link

  • Henri Jaton 0

    I just don’t understand which version of .Net Core I must use to use the lastest version of blazor (3.1.0-preview4.19579.2) can you put me the direct link ? I have this error and I can’t compile: ILLink failed with exited code 1…
    Webassembly of course.
    And which version of VS2019 ?
    Thanks in advance…
    Managed with that: Blazor: Mono linker path not properly quoted #17754

  • Nemanja Stolic 0

    I had to add –update-apply to install web assembly template

    dotnet new –install Microsoft.AspNetCore.Blazor.Templates::3.1.0-preview4.19579.2 –update-apply

  • Jeff Johnson 0

    Unable to debug into azure functions in .net core 3.1, says no matching runtime, even though my project file has v3 and netcoreapp3.1… this is with latest VS 2019 on Windows 10 as of 2019-12-11.

      • Jeff Johnson 0

        The npm update for cli tools seems to have done it! Thanks so much for the help.

  • Ross 0

    After upgrading a Blazor WASM app from 3.1.0-preview3 to 3.1.0-preview4, static assets in BCL projects are no longer being “included” in my Blazor project.

    Clearly something has changed, as alluded to in the “Support for static assets in libraries when publishing” section of this article.

    The new instructions for Blazor BCL static assets (, simply links to But that latter page is for ASP.NET and doesn’t apply to Blazor WASM – for example, it wants you to use IApplicationBuilder.UseStaticFiles(), which isn’t available/applicable in Blazor WASM.

    How exactly should BCL static assets work in Blazor WASM 3.1.0-preview4?

Feedback usabilla icon