ASP.NET Core updates in .NET Core 3.1
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.
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:
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:
- Run the app without debugging (Ctrl-F5 instead of F5)
- Open the Debug properties of the app and copy the HTTP app URL
- Browse to the HTTP address (not the HTTPS address) of the app using a Chromium based browser (Edge Beta or Chrome).
- With the browser in focus, press Shift-Alt-D and then follow the instructions to open a browser with remote debugging enabled
- Close all other browser instances
- In Visual Studio, select Debug > Attach to Process.
- For the Connection type, select Chrome devtools protocol websocket (no authentication).
- 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).
- Select the browser process you want to debug and select Attach
- 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
- Set a break point in your app (for example, in the
IncrementCountmethod in the
Countercomponent) 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.
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!
Just Important Inputs to Microsoft.
Blazor need something like INotification property changed and Dependency Property.
Acquiring web assembly or building something similar to web assembly and keeping in Microsoft Control would be better.
Because java-script people are spreading remorse on web assembly stating web assembly is used build malicious app.
Build a new team or take Microsoft Blend Team to start supporting HTML and CSS in Blend.
HTML and CSS should be done in GUI itself like Microsoft Blend in wpf.
I’ve been looking forward to Blazor Webassembly updates–is there a good way to be appraised of those? In particular I am wanting to develop user accounts using .NET Core Identity best practices, and have been awaiting updates to Authentication & Authorization in Blazor (https://docs.microsoft.com/en-us/aspnet/core/security/blazor/?view=aspnetcore-3.1&tabs=visual-studio). I’d like to follow the best practices and have never dealt with Identity yet so I don’t want to do it incorrectly. Not even sure the best forum for this question though.
I’m now using Core 3.1 after many years of making .Net Framework apps. It bugs me to see country folders (es, fr, etc.) in my bin output folder, and the “Runtimes” folder with Unix, etc. that I don’t need. I’m using Visual Studio 16.x to make ASP.Net Core apps.
Can we prevent these folders from getting created? A post-build clean-up event would work, but I want to prevent it.
I’ve created a new Blazor WASM project using .net core 3.1 and deployed to Azure App Service.
The Safari on my iOS13 device (iPhone11) still gets the error of exceeding the maximum size.
How can I fix this?