Blazor WebAssembly 3.2.0 Release Candidate now available

Daniel Roth

The Blazor WebAssembly Release Candidate is here! This release contains all of the features and improvements that we expect to release for the upcoming Blazor WebAssembly release. There are no more breaking changes planned at this point. Please give the Blazor WebAssembly Release Candidate a try and let us know what you think!

Here’s what’s new in this release:

  • Custom boot resource loading
  • API reference docs

Get started

To get started with Blazor WebAssembly 3.2.0 Release Candidate, 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 --version from 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-rc1.20223.4

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

Upgrade an existing project

To upgrade an existing Blazor WebAssembly app from 3.2.0 Preview 5 to the 3.2.0 Release Candidate:

  • Update all Microsoft.AspNetCore.Components.WebAssembly.* package references to version 3.2.0-rc1.20223.4.
  • Update any Microsoft.AspNetCore.Components.WebAssembly.Runtime package references to version 3.2.0-rc1.20222.2 (having a reference to this package is uncommon).
  • Update all System.Net.Http.Json package references to 3.2.0-rc1.20217.1

You’re all set!

Custom boot resource loading

When a Blazor WebAssembly app loads in the browser, it first downloads all of the required boot resources from the server, including the .NET runtime, the bootstrapping JavaScript code, locale specific data, and the .NET assemblies that make up the app. You can now customize how these boot resources are loading using the loadBootResource API. You can use this API to make any needed modifications to how these specific outbound requests are constructed. For example, you might want to load some of the resources from an external CDN. Although Microsoft does not currently host the Blazor framework files on any specific public Content Delivery Network (CDN), you are free to add them to your own CDN if you wish. For example, if you have published the _framework\wasm files to a CDN within the base URL, then you could configure your application to use those resources as follows:

<script src="_framework/blazor.webassembly.js" autostart="false"></script>
        loadBootResource: function (type, name, defaultUri, integrity) {
            console.log(`Will load '${type}' with name '${name}' from URI '${defaultUri}' and integrity '${integrity}'`);

            switch (type) {
                case 'dotnetjs':
                case 'dotnetwasm':
                case 'timezonedata':
                    return `https://mycdn.external.cdn/blazorwebassembly/3.2.0-rc1/${name}`;

            // Other types are 'assembly' and 'pdb' but you probably wouldn't want to fetch those from a CDN as they would be custom-linked for your app
            // By returning undefined for other types, we let the framework use its normal strategy for those types

If you want to customize more than just the URLs that are being used, then your loadBootResource function can call fetch directly and return the result. For example:

<script src="_framework/blazor.webassembly.js" autostart="false"></script>
        loadBootResource: function (type, name, defaultUri, integrity) {
            // Adds a custom HTTP header to the outbound requests
            // To retain the default integrity checking behavior, it's necessary to pass through the 'integrity' parameter
            return fetch(defaultUri, { 
                cache: 'no-cache',
                integrity: integrity,
                headers: { 'MyCustomHeader': 'My custom value' }

API reference docs

API reference docs for the Blazor WebAssembly namespaces (Microsoft.AspNetCore.Components.WebAssembly.*) are now available in the .NET API browser as part of the ASP.NET Core 3.1 API docs.

Known issues

  • When publishing a ASP.NET Core hosted Blazor WebAssembly app using Visual Studio, satellite assemblies from the client application do not get copied to the publish folder.

    This issue will be addressed in the upcoming release. To workaround this issue, publish the app from the command line using dotnet publish.


This is our last planned preview release of Blazor WebAssembly 3.2! We need your help to make sure that we’ve addressed any remaining blocking issues for the upcoming release. Please give it a try and let us know what you think by filing issues on GitHub.

We hope you enjoy the Blazor WebAssembly Release Candidate and thanks for trying out Blazor!


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

  • Max Popov 0


    Thanks for that new release.

    In the dotnet command, the ‘dot’ at the end must be deleted.

    dotnet new -i Microsoft.AspNetCore.Components.WebAssembly.Templates::3.2.0-rc1.20223.4

    • Daniel RothMicrosoft employee 0

      Hi Max. Thanks for letting us know! Should be fixed now.

  • Wade Balzer 0

    Hi Daniel,

    Do you know if anyone has figured out the problem with the Register link in MS Edge? I have never got it to work in any of the releases. Maybe it is just my machine running MS Edge and every VM I create and update? It DOES seem to work in Chrome, but it has definitely never worked for me in MS Edge.

    crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
          Unhandled exception rendering component: Invalid calling object
          TypeError: Invalid calling object
             at Anonymous function (https://localhost:44321/_framework/blazor.webassembly.js:1:9866)
             at Promise (native code)
             at e.jsCallDispatcher.beginInvokeJSFromDotNet (https://localhost:44321/_framework/blazor.webassembly.js:1:9835)
             at _mono_wasm_invoke_js_marshalled (https://localhost:44321/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js:1:171315)
             at Module[_mono_wasm_invoke_method] (https://localhost:44321/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js:1:195702)
             at BINDING.call_method (https://localhost:44321/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js:1:160862)
             at Anonymous function (https://localhost:44321/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js:1:163131)
             at beginInvokeDotNetFromJS (https://localhost:44321/_framework/blazor.webassembly.js:1:41356)
             at s (https://localhost:44321/_framework/blazor.webassembly.js:1:8558)
             at e.invokeMethodAsync (https://localhost:44321/_framework/blazor.webassembly.js:1:9634)
    Microsoft.JSInterop.JSException: Invalid calling object
    TypeError: Invalid calling object
       at Anonymous function (https://localhost:44321/_framework/blazor.webassembly.js:1:9866)
       at Promise (native code)
       at e.jsCallDispatcher.beginInvokeJSFromDotNet (https://localhost:44321/_framework/blazor.webassembly.js:1:9835)
       at _mono_wasm_invoke_js_marshalled (https://localhost:44321/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js:1:171315)
       at Module[_mono_wasm_invoke_method] (https://localhost:44321/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js:1:195702)
       at BINDING.call_method (https://localhost:44321/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js:1:160862)
       at Anonymous function (https://localhost:44321/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js:1:163131)
       at beginInvokeDotNetFromJS (https://localhost:44321/_framework/blazor.webassembly.js:1:41356)
       at s (https://localhost:44321/_framework/blazor.webassembly.js:1:8558)
       at e.invokeMethodAsync (https://localhost:44321/_framework/blazor.webassembly.js:1:9634)
      at System.Threading.Tasks.ValueTask`1[TResult].get_Result ()  in :0 
      at Microsoft.JSInterop.JSRuntimeExtensions.InvokeVoidAsync (Microsoft.JSInterop.IJSRuntime jsRuntime, System.String identifier, System.Object[] args)  in :0 
      at Microsoft.AspNetCore.Components.WebAssembly.Authentication.RemoteAuthenticatorViewCore`1[TAuthenticationState].OnParametersSetAsync ()  in :0 
      at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion (System.Threading.Tasks.Task task)  in :0 
      at Microsoft.AspNetCore.Components.ComponentBase.RunInitAndSetParametersAsync ()  in :0 
      at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask (System.Threading.Tasks.Task taskToHandle)  in :0 
    blazor.webassembly.js (1,37753)
    • Daniel RothMicrosoft employee 0

      Hi Wade. Could you please file an issue on GitHub for this if you haven’t already?: I’m not able to reproduce this issue myself – registering a new user works fine in Edge 81.0.416.64 for me. So when you file the issue please include as many details as you can on how to reproduce the problem. Thanks for your patience on this one!

      • Wade Balzer 0

        I figured out the issue. It’s still a bug, but now I understand the discrepancy. When I install Windows 10 v. 1909, and perform all needed Windows Updates, and I install VS 2019 v16.6 updated to Preview 5, and install the latest Blazor WASM,… at no time was I made aware that my version of MS Edge was not sufficient, or that I needed to download a newer version of Microsoft Edge. Yes… I remember reading that I needed a Chromium based browser such as MS Edge, but that didn’t inform me that my version was inadequate. That just told me that if I had MS Edge, I was “good to go”. By default… most everyone in my company will not have updated to the new version of MS Edge if it isn’t part of a Windows Update… and trust me… I assumed because there were no updates available, I had the latest. I was running:

        Microsoft Edge 44.18362.449.0
        Microsoft EdgeHTML 18.18363

        When I UPDATED to Version 81.0.416.68 (Official build) (64-bit), the problem I have been having went away.

        That leads me to the next question… Which browsers are officially supported, and will there be a mass rollout of the new MS Edge? I’m trying to decide what I need to do for backwards compatibility or some fall back support for older browsers.

          • Wade Balzer 0

            Hi Daniel, I appreciate the clarification on the browsers supported. My issue is that until the new MS Edge is included in a Windows Update, or a new distribution of Windows 10, a user is required to somehow be notified that the new Edge exists, and that they would need to manually download and update their system. Currently, the most current MS Edge browser available in a Windows update is the Legacy Edge Browser which has the problem. Since I began reporting this issue, it was only when you told me that you were running Edge v81 that I discovered the discrepancy with my Edge v44 which then led me to Google your version and find that the new Edge exists.

            All that to say.. that if the “current” Edge is still the Legacy Edge which is not a supported platform, how would be the best way to notify the user that they need to update? Is there a component that you’d recommend for Browser capabilities in Blazor?

          • Daniel RothMicrosoft employee 0

            Hi Wade. Your concern makes complete sense. We’ve been talking to the Edge team about how soon they expect the new version of Edge to be rolled out on Windows Update, and it sounds like they expect that to happen reasonably soon for end users. Enterprises will of course still have control over when the new version of Edge rolls out, but we expect widespread adoption. So hopefully this will just be a reasonably short point in time issue. Unfortunately we don’t have a recommended component for detecting browser versions or capabilities. You’d most likely need some JS interop code for that.

  • Rod Macdonald 0

    With Blazor Web Assembly reaching release candidate status, is it time to start calling ‘Razor’ components ‘Blazor’ components? It’s one of those small ‘marketing’ things that make it easier to communicate new app development to customers who might want to take up on this exciting development as Build approaches.

    Haven’t tried the .NET 5 preview. For .NET 5 era Blazor Web Assembly apps, will they be running against Core or Mono, and presumably if the former, there will be breaking changes which could be significant?

    Thank you.

    • Daniel RothMicrosoft employee 0

      Hi Rod. It’s absolutely fine to treat Razor components and Blazor components as synonyms, but the technical term is still Razor components. The main reason for this is that we’ve learned over the years that it’s best to keep core runtime and framework concepts independent of the whims of marketing and branding.

      Blazor WebAssembly apps in .NET 5 will still be based on the existing .NET IL interpreter, but we expect to align on the same core framework library implementations as the rest of .NET Core. We also expect to enable ahead of time (AoT) compilation to WebAssembly to improve runtime performance. We do not expect any significant breaking changes as part of these changes. Blazor derives much of its value from its community and ecosystem, so maintaining compatibility is paramount.

      • Todd Albers 0

        Keeping core runtime and framework concepts independent of the whims of marketing and branding is understandable. Also, I would think backward compatibility is a factor. You don’t want to break previously created .razor projects. And one could argue that “Blazor” is really just a progressive step forward of “Razor”. So, why change the name (beyond marketing and branding)? Because even though it is the same, it’s really not. Respectfully, I think that even though they are the same in many ways, they really aren’t the same thing (beyond just marketing and branding). So, I tend to agree with Rod’s general thought\idea above.

        Note the text below is based on: I am using Visual Studio 16.7.0 Preview 1.0, with .NET Core SDK 3.2.0-rc1.20223.4, and .Net Core 3.1.300 described above. Also, if I get any details wrong here, I may be misunderstanding some things about how razor and blazor are set up and used. So, please forgive me if I get something wrong here and feel free to let me know. Also, I recognize that this is a “Preview” version of Visual Studio. But, I think that most of this is not related to whether it is a release or preview version.

        There is a difference between “Razor” and “Blazor” and pushing more toward the “Blazor” term (and away from “Razor”) reinforces that there really is something new and different about this. And there is. It isn’t just the same “Razor” platform with a different name to jazz things up. It is some new and exciting stuff, called Blazor.

        Keeping (forcing) some aspects to be known as “razor” going forward while other parts are called blazor is confusing. Here are some examples.

        In Visual Studio, in the “Create a new project” screen there is a “Blazor App” option but no “Blazor Class Library” option. Furthermore, there is a “Razor Class Library” option, but no “Razor App” option. This is a bit confusing in appearance.

        Using the “.razor” (file extension) in “blazor” projects is also a little convoluted and I think adds a bit more confusion, especially for people new to Microsoft development who are trying to “check out this new ‘blazor’ stuff”. (ie -What’s this “buzz” regarding the new “Blazor” thing that Microsoft came out with?)

        “Razor Pages” (not app or web app) is one of a few options listed under the “ASP.NET Core Application” project type (under which Blazor project type is an option also, but it’s not listed).

        If you search for “Blazor” on the “Create a New Project” screen the result is four project options but only one has the word “Blazor” in it. The results are: “Blazor app”, “Razor Class Library”, “ASP.NET Core Web Application”, and “ASP.NET Core Web Application”.

        That’s not a type-o. “ASP.NET Core Web Application” is listed twice in the results. Probably because there are two entries for options behind the scenes: one for “Razor” and one for “Blazor”. (Just a guess) But, neither descriptions for “ASP.NET Core Web Application” mention “Blazor”. (Again – Noted that this is a preview version of Visual Studio).

        I think “Razor” and “Blazor” are different and should be differentiated. I think keeping “razor” around just muddies the water more for people trying to learn Blazor.

        However, I think there is a relatively easy way to segregate actual “Razor” from “Blazor”. How about a compromise? Blazor server was released with .NET Core 3.0. Maybe do or allow this? Maybe for any “project” with TargetFramework of netcoreapp3.0 or greater, create an optional project setting named (something like): “Razor\Blazor code file extension:” or “Razor\Blazor Project Type:”. And then allow the following four options: (1) Either, (2) Both, (3) Blazor, (4) Razor.

        If the setting is missing (like in the project file for an older project built before “netcoreapp3.0”) then the setting defaults to: “(1) Either”.


        (1) Either – [ie “Xor”] Allows file extensions in the same project to be exclusively either “.razor” or “.blazor”. It treats them the same. But, all files must have the same extension – either “.razor” or “.blazor”.

        (2) Both – [ie “Or”] Allows file extensions in the same project to be “.razor” or .blazor” but not exclusively. Some can be “.razor” while some can be “.blazor” It treats them the same. But, both file types can exist in same project. (Maybe not this option. I can’t think of a reason of why someone would need this. But, maybe a situation where someone is trying to convert a project from purely “razor” to purely “blazor”over time??? [so can implement webassembly for example] .)

        (3) Blazor – All files must have the extension of “.blazor”. File extensions of “.razor” error out with a suggestion to change them to “.blazor” or change this project setting.

        (4) Razor – All files must have the extension of “.razor”. File extensions of “.blazor” error out with a suggestion to change them to “.razor” or change this project setting.

        If this was implemented, current “Blazor” projects could have this option added into the project file automatically or manually after the upgrade to visual studio version that implements this. Then, you could also offer “Blazor Class Library” which would simply require the .blazor file extension (optionally) and this setting in the project file. I think that having both “Blazor app” and “Blazor Class Library” as options is clearer and better overall. It also helps promote the “marketing” and promotional aspects of this new (what some people are calling “a game changer”) “Blazor” thing that Microsoft has come out with.

        I think that would work. And it doesn’t seem too difficult to implement. I might try to jump into the Open Source code and play with the idea, but someone else can probably do it a lot easier and faster than I can as I’m not familiar with the Open Source code. And really you guys need to decide if you think it is a good idea or not first. There may be something I am not thinking of or don’t realize that makes this not possible or not a good idea. I think it is worth doing or at least considering. I think that Razor and Blazor are different.

        I also think there should be a “C# Blazor Web Developer” certification available btw. Would really like that. šŸ™‚

        All of this is offered respectfully and is just my general take on it. I’m not sure how others might think of it. Also, there might be some things that I don’t see\realize\understand that makes this a bad or difficult implementation.

        Thank you for your consideration.

        Todd Albers

        PS – Great job, to you and your team on getting webassembly to Release! I think this is all pretty exciting progress.

        • Wil Wilder Apaza Bustamante 0

          this comment has been deleted.

  • Julio Avellaneda 0

    Good news Daniel, I’m wondering about the support to deploy a new Blazor wasm (without aspnet hosted option) application on an Azure App Service using linux version, do you know if this is possible?

    Currently I have it live as an azure storage static web site, but I want to move it to app service.


    • Daniel RothMicrosoft employee 0

      Hi Julio. It should be possible to deploy an ASP.NET Core hosted Blazor WebAssembly app on Azure App Service Linux. If you’re finding that isn’t the case, let us know!

      What isn’t supported yet is deploying a standalone Blazor WebAssembly app to Azure App Service Linux. Unlike Azure App Service on Windows, which comes setup with IIS, the Linux version doesn’t include a web server to host the Blazor WebAssembly files. We’re working with the Azure App Service folks on what to do about that.

      • Daniel RothMicrosoft employee 0

        It looks like Azure App Service Linux lets you define a ecoysystem.config.js which tells the service what processes to start up. For example, with this content it will run a Node-based server for the static content.

        module.exports = {
          apps: [ { script: "npx serve -s" } ]
        • Julio Avellaneda 0

          Thank you Daniel, my blazor is a standalone app, is on the app service roadmap the support for this blazor apps? If not, i can take sometime to add the aspnet core app to host my blazor app.

          • Daniel RothMicrosoft employee 0

            We’re working on it, but I can’t give you a specific timeframe for when it will be addressed. My recommendation would be to switch to hosting the app with ASP.NET Core for now.

  • Eddy 0

    Is this the “May Release Release”? from the words RC means Candidate meaning it is not the actual release. When will the actual release be? Will there be a .net core 3.2 in may?

    • Thomas Tomiczek 0

      You are aware that a “may release” may happen last day f may? The way I read it they want this checked and may release in a week or two, depending on critical bugs found.

    • Daniel RothMicrosoft employee 0

      Hi Eddy. No, this isn’t the May release. That’s still to come. This is the release candidate for the May release. Just a few more weeks to go!

      No, there isn’t a .NET Core 3.2 release planned. We versioned Blazor WebAssembly as 3.2 to distinguish it from the rest of .NET Core 3.1 LTS. Blazor WebAssembly 3.2 will be a Current release, not an LTS release. We generally like to ship something a couple of times before we declare an LTS release.

      • Eddy 0

        Thank you for clarifying things out. Hopefully it ships with a version of .net core so it would be easier to create projects with cli templates.

        • Daniel RothMicrosoft employee 0

          The Blazor WebAssembly 3.2 template will ship with the .NET Core 3.1 SDK starting with version 3.1.300. But it will not inherit the LTS status of .NET Core 3.1. Blazor WebAssembly 3.2 will be treated as a Current release.

  • Stephen Brown 0

    Hi Daniel,

    This is great news, so exciting that Blazor is nearing release. One question I have is around the DLL extensions. Will Blazor still download assemblies for apps with a .dll file extension? Will the general release provide a way to change this in case corporate firewalls and virus software block the downloading of these when they appear in a Blazor app?


  • Russ Sherlock 0

    When editing a WebAssembly .razor file, my code displays many Red Squiggles which indicate source code errors, but the project compiles without any errors?

    Typically the errors relate to methods that belong to a base class and the .razor files reference them by @inherits SomeBaseClass.
    N.B. A clean rebuild and VS restart does not solve this issue.

    Refactoring (renaming) still also fails after the second typed letter.

    Is everybody just putting up with this or is this an issue unique to me? (I have been assuming that these issues are well known)

    • Tom Woodforde 0

      Russ, are you using Resharper by any chance? If so that could be the cause, there are a number of Blazor related issues the R# team are still working through. Updating to the latest version of R# will get rid of a lot of the false red squigglies. If you’re using it.

    • Mark Lawrence 0

      I see this also, and to be honest, I’m used to it from the experience I have with Angular in VS Code, which does very similar things for me. I just ignore it, and it generally clears up fairly quickly anyway for me. It seems to be some kind of lag in the real-time compilation the editor uses to highlight, or something like that.

  • RaphaĆ«l Desalbres 0

    Hi Daniel,

    I have a performance issue using Webassemly Blazor.
    For example this site was made using Server-Side Blazor, and has a grade of ~ 70 using :

    The same site made with Webassembly grades ~ 40 !

    Any idea of this bad performance ?

    Thank you very much,


    • Daniel RothMicrosoft employee 0

      Hi Raphaƫl. Probably best to open a GitHub issue with some details on how your app is implemented so that we can dig into how best to help out with these performance issues:

  • Vincent Anzelone 0

    Is there any way to get Browser Link to work with Blazor WASM? I’m using the latest version of the Visual Studio 2019 Preview and have both the Web Essentials and the Microsoft.VisualStudio.Web.BrowserLink package installed. No matter what I do BrowerLink says that it’s disabled and shows no connections in the BrowserLink dashboard.

    • Daniel RothMicrosoft employee 0

      No, we don’t support Browser Link with Blazor.

  • Karthik D V 0

    Hi Daniel, Its good to see RC 1! I’m waiting for the release.
    Is there a plan to improve the DEBUG experience and the hosting on issues without having to deal with route issues?
    I have VS 16.6.0 Preview 5.0 yet struggling to do basic debugging.
    Currently, I’m struggling to handle routes when I publish the core hosted WASM on the IIS server. Is there clear documentation on how around these routings?

    • Daniel RothMicrosoft employee 0

      Hi Karthik. We do know that there are still a bunch of rough spots with the debugging experience. We will likely try to squeeze in some more fixes for those for the May release. To make sure we have addressed the specific issues you are seeing, please send us the details by submitting issues on GitHub:

      I’m not sure I understand what issues your having with handling routes, but again, it’s best if you submit that feedback directly to GitHub: Be sure to include details on what you’re trying to do and how to reproduce the problem you are seeing.

Feedback usabilla icon