A new preview update of Blazor WebAssembly is now available! Here’s what’s new in this release:
- Access host environment during startup
- Logging improvements
- Brotli precompression
- Load assemblies and runtime in parallel
- Simplify IL linker config for apps
- Localization support
- API docs in IntelliSense
Get started
To get started with Blazor WebAssembly 3.2.0 Preview 4 install the latest .NET Core 3.1 SDK.
NOTE: Version 3.1.201 or later of the .NET Core SDK is required to use this Blazor WebAssembly release! Make sure you have the correct .NET Core SDK version by running
dotnet --versionfrom a command prompt.
Once you have the appropriate .NET Core SDK installed, run the following command to install the updated Blazor WebAssembly template:
dotnet new -i Microsoft.AspNetCore.Components.WebAssembly.Templates::3.2.0-preview4.20210.8
If you’re on Windows using Visual Studio, we recommend installing the latest preview of Visual Studio 2019 16.6. For this preview you should still install the template from the command-line as described above to ensure that the Blazor WebAssembly template shows up correctly in Visual Studio and on the command-line.
That’s it! You can find additional docs and samples on https://blazor.net.
Upgrade an existing project
To upgrade an existing Blazor WebAssembly app from 3.2.0 Preview 3 to 3.2.0 Preview 4:
- Update all Microsoft.AspNetCore.Components.WebAssembly.* package references to version 3.2.0-preview4.20210.8.
- Update any Microsoft.AspNetCore.Components.WebAssembly.Runtime package references to version 3.2.0-preview5.20210.1
- Replace package references to Microsoft.AspNetCore.Blazor.HttpClient with System.Net.Http.Json and update all existing System.Net.Http.Json package references to 3.2.0-preview5.20210.3.
-
Add
@using System.Net.Http.Jsonto your _Imports.razor file and update your code as follows:Microsoft.AspNetCore.Blazor.HttpClient System.Net.Http.Json GetJsonAsyncGetFromJsonAsyncPostJsonAsyncPostAsJsonAsyncPutJsonAsyncPutAsJsonAsyncCalls to
PostAsJsonAsyncandPutAsJsonAsyncreturn anHttpResponseMessageinstead of the deserialized response content. To deserialize the JSON content from the response message, use theReadFromJsonAsync<T>extension method:response.content.ReadFromJsonAsync<WeatherForecast>(). -
Replace calls to
AddBaseAddressHttpClientin Program.cs withbuilder.Services.AddSingleton(new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });. - Update service registrations that depend on
IAccessTokenProviderto be scoped services instead of singleton services.
You’re all set!
Access host environment during startup
The WebAssemblyHostBuilder now exposes IWebAssemblyHostEnvironment through the HostEnvironment property, which surfaces details about the app environment (Development, Staging, Production, etc.) during startup. If the app is hosted in an ASP.NET Core app, the environment reflects the ASP.NET Core environment. If the app is a standalone Blazor WebAssembly app, the environment is specified using the blazor-environment HTTP header, which is set to Development when served by the Blazor dev server. Otherwise, the default environment is Production.
New convenience extension methods on IWebAssemblyHostEnvironment make it easy to check the current environment: IsProduction(), IsDevelopment(), IsStaging(). We’ve also added a BaseAddress property to IWebAssemblyHostEnvironment for getting the app base address during startup when the NavigationManager service isn’t yet readily available.
Logging improvements
The WebAssemblyHostBuilder now exposes a Logging property of type ILoggingBuilder that can be used to configure logging for the app, similar to how you would configure Logging in an ASP.NET Core app on the server. You can use the ILoggingBuilder to set the minimum logging level and configure custom logging providers using extension methods in the Microsoft.Extensions.Logging namespace.
Brotli precompression
When you publish a Blazor WebAssembly app, the published and linked output is now precompressed using Brotli at the highest level to further reduce the app size and remove the need for runtime compression. ASP.NET Core hosted apps seamlessly take advantage of these precompressed files. For standalone apps, you can configure the host server to redirect requests to the precompressed files. Using the precompressed files, a published Blazor WebAssembly is now 1.8MB, down from 2MB in the previous preview. A minimal app without Bootstrap CSS reduces to 1.6MB.
Load assemblies and runtime in parallel
Blazor WebAssembly apps now load the assemblies and runtime in parallel saving some precious milliseconds off the app load time.
Simplify .NET IL linker config for apps
You can optionally provide a .NET IL linker config file for a Blazor WebAssembly app to customize the behavior of the linker. Previously, specifying a linker config file for your app would override the customizations built into Blazor that are necessary for apps to function property. App specific linker configuration is now treated as additive to the linker configuration provided by Blazor.
Localization support
Blazor WebAssembly apps now support localization using .NET resource files (.resx) and satellite assemblies. Blazor WebAssembly apps set the current culture using the user’s language preference. The appropriate satellite assemblies are then loaded from the server. Components can then be localized using the ASP.NET Core localization APIs, like IStringLocalizer<TResource> and friends. For more details on localizing Blazor WebAssembly apps, see Globalization and localization.
API docs in IntelliSense
The API docs for the various Blazor WebAssembly APIs are now available through IntelliSense:
Known issues
Debugging limitations
Thank you everyone who has been trying out the new Blazor WebAssembly debugging support and sending us your feedback! We’ve made some progress in this release, but there are still a number of limitations with the current debugging experience in Visual Studio and Visual Studio Code. The following debugging features are still not yet fully implemented:
- Inspecting arrays
- Hovering to inspect members
- Step debugging into or out of managed code
- Full support for inspecting value types
- Breaking on unhandled exceptions
- Hitting breakpoints during app startup
We expect to continue to improve the debugging experience in future releases.
Help improve the Blazor docs!
We’ve received a some feedback from the in-product Blazor survey that the Blazor docs could use some improvement. Thank you for this feedback! We know that docs are a critical part of any software development framework, and we are committed to making the Blazor docs as helpful as we can.
We need your help to understand how to best improve the Blazor docs! If you’d like to help make the Blazor docs better, please do the following:
-
As you read the Blazor docs, let us know where we should focus our efforts by telling us if you find a topic helpful or not using the helpfulness widget at the top of each doc page:
-
Use the Feedback section at the bottom of each doc page to let us know when a particular topic is unclear, inaccurate, or incomplete.
-
Comment on our Improve the Blazor docs GitHub issue with your suggestions for new content and ways to improve the existing content.
Feedback
We hope you enjoy the new features in this preview release of Blazor WebAssembly! Please let us know what you think by filing issues on GitHub.
Thanks for trying out Blazor!
Hi, I just started developing an app with blazor wasm + web api and I really like it. One thing on my wish list is a BLAS library/routines, especially vector-matrrix multiplications. In addition to thiis I would love to be able to use parallel execution!!!
Is it possible to re-use existing satellite assemblies for localization?
We have a dedicated project for localization which we consume through nuget in our desktop applications. The
<code>
assumes I have resource files per razor page and is not picking up the provided assemblies.
When I try to directly use the ResourceManager from our Nuget package I get a runtime error with the following description:
<code>
.
The nuget package is a netstandard2.0/2.1 lib so it should work, right?
Hello Daniel, successfully upgraded to preview 5, but wanted to leave the comment here because this is where the API calls were changed. I'm getting the following error calling my API's GET method using the GetFromJsonAsync change in this version:
Unhandled exception rendering component: The provided ContentType is not supported; the supported types are 'application/json' and the structured syntax suffix 'application/+json'
My current API output is: text/plain; charset=utf-8
This was working with previous versions, but now it is...
Hi Robert. I believe the current behavior is by design. The
GetFromJsonAsyncmethod expects the response content to be JSON. I’m not sure why it was working before for text/plain, but I don’t think that was the intent. If you think this scenario should be supported by System.Net.Http.Json, please file an issue on GitHub in the https://github.com/dotnet/runtime/issues repo.Ok, thanks for the quick response. I’ll make the changes to my API to return the JSON content type. Strange it was working before.
My Blazor App (3.2.0 Preview 4) runs fine locally using Visual Studio but when I try and deploy it to IIS I get an error, I have deployed it before when it was a 3.2.0 preview 3 app with no problems :
error : Unhandled exception. Mono.Linker.Steps.XmlResolutionException: Failed to process XML description:
1> ---> Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'Microsoft.AspNetCore.Blazor.HttpClient, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
1> ---> Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'Microsoft.AspNetCore.Blazor.HttpClient, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
1> ...
Hi Paul
We had the same issue while publishing the Blazor App.
It seems the publish works only with Target Runtime: Portable.
Also, it would be useful if we could take a look at what you have in your project file to make sure you don’t have any MSBuild additions that might be affecting things.
Hi Paul. It does sound like something has gotten out of sync. If you delete your bin & obj folders and rebuild and republish, does that resolve the issue?
Blazor performance is very good in mid and high end devices but in low end devices it is extremely poor, we started building a product on blazor, now we are worried about its performance.
Mainly following things...
. Json de-serialization is damn slow using NewtonSoft.
. Moving data through methods from javascript to c# or c# to javascript also taking much time.
Is blazor is recommended for low end devices which have 1.2Ghz speed and dual...
Hi Manoj.
Have you tried using the new System.Text.Json serializer instead of Newtonsoft.Json? We moved Blazor to use System.Text.Json some time ago and it does provide some performance improvements.
Also, if you need to push a lot of data through JavaScript interop there is a Blazor WebAssembly specific mechanism for unmarshalled interop calls: https://github.com/dotnet/aspnetcore/blob/master/src/JSInterop/Microsoft.JSInterop/src/IJSInProcessRuntime.cs. It's not well documented and it's pretty low level, but it is available for advanced scenarios.
The .NET runtime used by Blazor WebAssembly is...
Thanks you so much for the detailed reply…
For us only concern is performance, apart from that blazor framework is helping us to build the product very quickly and deployments became very simple.
Please give us better performance in upcoming versions and
provide some articles for recommended way to develop blazor apps without hitting performance.
Hi Manoj. Thanks for this feedback! I’ve filed https://github.com/dotnet/aspnetcore/issues/21112 to track adding documentation for performance best practices. We have some performance improvements, like AoT compilation, planned for .NET 5 as well.
Thanks for your work!
Can I continue to use older PostJsonAsync extensions? Or with new PostAsJsonAsyncor instead of new ?
I need to return objects in Post as in PostJsonAsync. Because these are processed objects on the server and their change is necessary on the client. so I need get back object after PostJsonAsync .
Hi Marina. The older PostJsonAsync methods that shipped as part of the Microsoft.AspNetCore.Blazor.HttpClient are being replaced with the new methods in System.Net.Http.Json. The new method returns an , but you can still deserialize the response body into a .NET object by calling on the response content, like this:
Hi, Daniel. Thanks, you helped me. Successfully move to System.Net.Http.Json. In documentation https://docs.microsoft.com/en-us/aspnet/core/blazor/call-web-api?view=aspnetcore-3.1 for first look not clear.
Hi Marina. I think the Call a Web API doc has been updated at this point, but let us know if you think the doc could still be improved!
Sample
I fired up a new Blazor WASM project using the latest template and added OidcAuthentication. My auth server is adding roles which can be seen in the JWT Bearer token that is found in the Session Storage. When using AuthorizeView or AuthorizeAttribute with Roles it is not picking up the roles from the access_token.
Sample Claims from access_token when debugged with jwt.io debugger and outputting it in an AuthorizeView-Authorized block:
Claim Type: http://schemas.microsoft.com/ws/2008/06/identity/claims/role
Claim Value:...
Hi Darren. For instructions on setting up roles with IdentityServer see https://github.com/dotnet/AspNetCore.Docs/issues/17649. We don’t read additional claims from the access token by default, but you can implement your own AccountClaimsPrincipalFactory to enrich the user ClaimsPrincipal with them. See https://github.com/dotnet/AspNetCore.Docs/issues/17650 for additional details.
Dan, how is gRPC-Web coming when WASM goes GA in May?
Hi Ben. The gRPC-web support for .NET is coming along in the https://github.com/grpc/grpc-dotnet/ repo. They are working towards shipping a stable release, but there’s no concrete release date yet.
HI, do you plan to compile blazor like svelte? is too much 6MB for a small app.
A published Blazor WebAssembly app is actually a lot smaller than 6MB. When the app is published. Blazor will run the .NET assemblies through a .NET IL linker that removes unneeded code and then aggressively compresses the app files using Brotli. A minimal Blazor WebAssembly app (no Bootstrap or other accessories) is only about 1.6MB. After the initial download the runtime and framework files are cached so subsequent loads are much quicker. That said, we're...
Hi Daniel,
I have upgraded my solution to Preview 4.
Everything works, even the debugger with PWA.
Apart from the notes you have written, I have created a new empty solution with the new templates and found multiple semplifications in the project structure that are not listed in this article.
I have applied them as well, and everything seems to be working fine as well.
Thank you for your efforts in making Blazor such a wonderful piece...
Hi Damiano. I’m happy to hear your upgrade went smoothly! We did have issues with debugging PWAs in the previous preview, which was fixed for this release. It’s great to hear that’s now working for you! If you think there are additional migration steps we should add let me know!