Blazor WebAssembly 3.2.0 Preview 3 release now available

Daniel Roth

A new preview update of Blazor WebAssembly is now available! Here’s what’s new in this release:

  • Debugging in Visual Studio and Visual Studio Code
  • Auto-rebuild in Visual Studio
  • Configuration
  • New HttpClient extension methods for JSON handling

Get started

To get started with Blazor WebAssembly 3.2.0 Preview 3 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-preview3.20168.3

If you’re on Windows using Visual Studio, we recommend installing the latest preview of Visual Studio 2019 16.6. Installing Visual Studio 2019 16.6 Preview 2 or later will also install an updated version of the .NET Core 3.1 SDK that includes the Blazor WebAssembly template, so you don’t need to separately install it.

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 2 to 3.2.0 Preview 3:

  • Update all Microsoft.AspNetCore.Components.WebAssembly.* package references to version 3.2.0-preview3.20168.3.
  • Update all Microsoft.AspNetCore.Blazor.* package references to version 3.2.0-preview3.20168.3.

You’re all set – easy peasy!


You can now debug Blazor WebAssembly apps directly from Visual Studio and Visual Studio Code. You can set breakpoints, inspect locals, and step through your code. You can also simultaneously debug your Blazor WebAssembly app and any .NET code running on the server. Using the browser dev tools to debug your Blazor WebAssembly apps is also still supported.

Enable debugging

To enable debugging in an existing Blazor WebAssembly app, update launchSettings.json in the startup project of your app to include the following inspectUri property in each launch profile:

"inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}"

This property enables the IDE to detect that this is a Blazor WebAssembly app and instructs the script debugging infrastructure to connect to the browser through Blazor’s debugging proxy.

Once updated, your launchSettings.json file should look something like this:

    "iisSettings": {
      "windowsAuthentication": false,
      "anonymousAuthentication": true,
      "iisExpress": {
        "applicationUrl": "http://localhost:50454",
        "sslPort": 44399
    "profiles": {
      "IIS Express": {
        "commandName": "IISExpress",
        "launchBrowser": true,
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        "environmentVariables": {
          "ASPNETCORE_ENVIRONMENT": "Development"
      "BlazorApp1.Server": {
        "commandName": "Project",
        "launchBrowser": true,
        "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
        "applicationUrl": "https://localhost:5001;http://localhost:5000",
        "environmentVariables": {
          "ASPNETCORE_ENVIRONMENT": "Development"

Visual Studio

To debug a Blazor WebAssembly app in Visual Studio:

  1. Ensure you have installed the latest preview release of Visual Studio 2019 16.6 or later.
  2. Create a new ASP.NET Core hosted Blazor WebAssembly app.
  3. Hit F5 to run the app in the debugger.
  4. Set a breakpoint in Counter.razor in the IncrementCount method.
  5. Browser to the Counter tab and click the button to hit the breakpoint:

    Debug Counter

  6. Check out the value of the currentCount field in the locals window:

    View locals

  7. Hit F5 to continue execution.

While debugging your Blazor WebAssembly app you can also debug your server code:

  1. Set a breakpoint in the FetchData.razor page in OnInitializedAsync.
  2. Set a breakpoint in the WeatherForecastController in the Get action method.
  3. Browser to the Fetch Data tab to hit the first breakpoint in the FetchData component just before it issues an HTTP request to the server:

    Debug Fetch Data

  4. Hit F5 to continue execution and then hit the breakpoint on the server in the WeatherForecastController:

    Debug server

  5. Hit F5 again to let execution continue and see the weather forecast table rendered.

Visual Studio Code

To debug a Blazor WebAssembly app in Visual Studio Code:

  1. Install the C# extension and the JavaScript Debugger (Nightly) extension with the debug.javascript.usePreview setting set to true.


    JS preview debugger

  2. Open an existing Blazor WebAssembly app with debugging enabled.

    a. If you get the following notification that additional setup is required to enable debugging, recheck that you have the correct extensions installed and JavaScript preview debugging enabled and then reload the window:

    Additional setup requried

    b. A notification should offer to add required assets for building and debugging to the app. Select “Yes”.

    Add required assets

  3. Starting the app in the debugger is then a two-step process:

    a. Start the app first using the “.NET Core Launch (Blazor Standalone)” launch configuration.

    b. Then start the browser using the “.NET Core Debug Blazor Web Assembly in Chrome” launch configuration (requires Chrome). To use the latest stable release of Edge instead of Chrome, change the type of the launch configuration in .vscode/launch.json from pwa-chrome to pwa-msedge.

  4. Set a breakpoint in the IncrementCount method in the Counter component and then select the button to hit the breakpoint:

    Debug Counter in VS Code

Known limitations

There are a number of limitations with the current debugging experience in Visual Studio and Visual Studio Code. The following debugging features are 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
  • Debugging an app with a service worker

We expect to continue to improve the debugging experience in future releases. We appreciate your feedback to help us get the Blazor WebAssembly debugging experience right!

Auto-rebuild in Visual Studio

Visual Studio 2019 16.6 will watch for file changes in .cs and .razor files across the solution and automatically rebuild and restart the app so that the changes can be seen by simply refreshing the browser. This enables auto-rebuild support for ASP.NET Core hosted Blazor WebAssembly projects and Razor Class Libraries. Instead of manually rebuilding and restarting the app when making code changes, just edit, save, and then refresh the browser.

To use auto-rebuild, run the app using IIS Express and without the debugger attached (Ctrl-F5 instead of F5).

Auto-rebuild is not yet enabled for standalone Blazor WebAssembly projects. With standalone Blazor WebAssembly apps, you can instead edit files, rebuild the app, and then refresh the browser without restarting the web server.


Blazor WebAssembly apps now have built-in support for loading configuration data from appsettings.json and environment specific configuration data from appsettings.{environment}.json.

To add configuration data to your Blazor WebAssembly app:

  1. Add an appsettings.json file in the wwwroot folder of your Blazor WebAssembly app:
    "message": "Hello from config!"
  1. Inject an IConfiguration instance into your components to access the configuration data.
@page "/"
@using Microsoft.Extensions.Configuration
@inject IConfiguration Configuration

<h1>Configuration example</h1>

  1. Run the app to see the configured message displayed on the home page.
  2. To optionally override this configuration with values specific to the Development environment, add an appsettings.Development.json to your wwwroot folder:
    "message": "Hello from Development config!"
  1. If you now run the app in Development, you’ll see the new message.

Note: Blazor WebAssembly apps load the configuration data by downloading the JSON files to the browser, so these configuration files must be publicly addressable. Do not store secrets in these configuration files, as they are public and can be viewed by anyone.

New HttpClient extension methods for JSON handling

The .NET team has been hard at work creating a full set of new extension methods for HttpClient that handle JSON serialization and deserialization using System.Text.Json. These extension methods are now available in preview with the System.Net.Http.Json package and they will replace the existing helper methods in the Microsoft.AspNetCore.Blazor.HttpClient package. We haven’t updated the Blazor WebAssembly template yet to use the new extension methods, but we will in our next Blazor WebAssembly preview update.

You can try the new extension methods yourself by replacing the Microsoft.AspNetCore.Blazor.HttpClient package with the newer System.Net.Http.Json package. Then add @using System.Net.Http.Json to your _Imports.razor file and update your code as follows:

Microsoft.AspNetCore.Blazor.HttpClient System.Net.Http.Json
GetJsonAsync GetFromJsonAsync
PostJsonAsync PostAsJsonAsync
PutJsonAsync PutAsJsonAsync

The updated implementation of the FetchData component in the default Blazor WebAssembly template looks like this:

@code {
    private WeatherForecast[] forecasts;

    protected override async Task OnInitializedAsync()
        forecasts = await Http.GetFromJsonAsync<WeatherForecast[]>("WeatherForecast");

System.Net.Http.Json also provides a JsonContent class that can be used for sending serialized JSON, as well as convenient helper methods for reading JSON from an HttpContent instance.

Look for more details on System.Net.Http.Json to be published soon on the .NET blog.

Known issues

There are a few known issues with this release that you may run into:

  • When building a Blazor WebAssembly app using an older .NET Core SDK you may see the following build error:
    error MSB4018: The "ResolveBlazorRuntimeDependencies" task failed unexpectedly.
    error MSB4018: System.IO.FileNotFoundException: Could not load file or assembly '\BlazorApp1\obj\Debug\netstandard2.1\BlazorApp1.dll'. The system cannot find the file specified.
    error MSB4018: File name: '\BlazorApp1\obj\Debug\netstandard2.1\BlazorApp1.dll' 
    error MSB4018:    at System.Reflection.AssemblyName.nGetFileInformation(String s)
    error MSB4018:    at System.Reflection.AssemblyName.GetAssemblyName(String assemblyFile)
    error MSB4018:    at Microsoft.AspNetCore.Components.WebAssembly.Build.ResolveBlazorRuntimeDependencies.GetAssemblyName(String assemblyPath)
    error MSB4018:    at Microsoft.AspNetCore.Components.WebAssembly.Build.ResolveBlazorRuntimeDependencies.ResolveRuntimeDependenciesCore(String entryPoint, IEnumerable`1 applicationDependencies, IEnumerable`1 monoBclAssemblies)
    error MSB4018:    at Microsoft.AspNetCore.Components.WebAssembly.Build.ResolveBlazorRuntimeDependencies.Execute()
    error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
    error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)

    To address this issue, update to version 3.1.201 or later of the .NET Core 3.1 SDK.

  • You may see the following warning when building from the command-line:
    CSC : warning CS8034: Unable to load Analyzer assembly C:\Users\user\.nuget\packages\microsoft.aspnetcore.components.analyzers\3.1.0\analyzers\dotnet\cs\Microsoft.AspNetCore.Components.Analyzers.dll : Assembly with same name is already loaded

    To address this issue, update to your package reference to Microsoft.AspNetCore.Components to 3.1.3 or newer. If your project reference the Microsoft.AspNetCore.Components package through a transitive package reference that has not been updated, you can add a reference in your project to resolve the issue in your project.

  • The following error may occur when publishing an ASP.NET Core hosted Blazor app with the .NET IL linker disabled:
    An assembly specified in the application dependencies manifest (BlazorApp1.Server.deps.json) was not found

    This error occurs when assemblies shared by the server and Blazor client project get removed during publish (see

    To workaround this issue, ensure that you publish with the .NET IL linker enabled. To publish with the linker enabled:

    • Publish using a Release build configuration: dotnet publish -c Release. The .NET IL linker is automatically run for Release builds, but not for Debug builds.
    • Don’t set BlazorWebAssemblyEnableLinking to false in your client project file.

    If you’re hitting issues running with the linker disabled, you may need to configure the linker to preserve code that is being called using reflection. See for details.


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!


Comments are closed. Login to edit/delete your existing comments

  • Morten Meisler 0

    I can’t get debugging to work, it doesn’t break.

    Using 3.1.300-preview-015048, latest VS preview 16.6. Creating a new blazor webassembly app from template (checked launchsettings are updated)

    Does it have to be hosted? I think that’s unclear, and if that’s the case, will there be support for client-side blazor debugging?

    • Daniel RothMicrosoft employee 0

      Hi Morten. Debugging should work for both standalone and ASP.NET Core hosted app. If you created the app using the latest version of the Blazor WebAssembly template then you shouldn’t need to update launchSettings.json – it should already be setup for debugging. Can you confirm that you are using the 3.2 Preview 3 version of the template?

      • Morten Meisler 0

        Thanks Daniel, glad it works for both. It actually works now, not sure what I did 🙂 Maybe restarting VS or something. But now it stopped correctly at currentCount++;

    • Fabian 0

      Hi Morten,

      I wonder how you managed to solve this – if it is the same problem here: My breakpoints do not register with the debugger (they become gray hollow circle when starting the debugger).

  • Indudhar Gowda 0

    Finally its give back time for Angular, they copied all best practices from WPF and Winforms implemented in Angular and Enjoyed for 6 Years.

    Now Blazor will implement all the best practices and features from Angular, Javascript, Jquery, NodeJS and Ensure they will never come back again.

    If they ever have to come back its the only way by New Innovation.

    I have said it in the past and say it again take the best out of all framework and Language which is thinner, Lighter and Faster and start implementing in Blazor,WPF and UWP. Most Importantly Open Source it.

  • Nick Whymark 0

    Yay, great work, thank you so much for the debugging! 🙂

    A couple of things that might be worth mentioning:

    I was upgrading an existing project which is Asp.Net core hosted and it may be worth pointing out you have to upgrade the launchsettings.json file in the Asp.Net core project. I was a little confused there for a few minutes….

    It works with Edge & Chrome but doesn’t work with Firefox. Also if you try it with Firefox it stops working for Edge and Chrome until I restart VS (might just be a solution reload, but I haven’t tried).

    You can’t seem to drill into List items when paused – I get “children cannot be evaluated”

    • Daniel RothMicrosoft employee 0

      Hi Nick. You’re correct that it’s the launchSettings.json in the startup project that needs to be updated to enable debugging. In an ASP.NET Core hosted Blazor WebAssembly app, that will be the server project. Debugging isn’t supported in Firefox at this time. There is also a known issue with inspecting collection types that we expect to address soon:

      • Guillaume ZAHRA 0

        Hi Daniel,

        Thanks for you and Nick to poiting out that Firefox is not yet supported, i was wondering why nothing was working.

        There was another missing thing for me, even with Chrome nothing was working. I had to click on the little arrow of the debug button in VS2019 while i was in debug mode, and i clicked on “Script debugging” => “Enabled”. Maybe worth to mention.

        It was not checked by default on my machine, maybe because i disabled some things while working with UWP and VS2019 crashing together a looooong time ago because of the script debugging feature.

        So if nothing happen even with Chrome or Edge, time to check if script debugging is enabled in VS !

        • Daniel RothMicrosoft employee 0

          There was another missing thing for me, even with Chrome nothing was working. I had to click on the little arrow of the debug button in VS2019 while i was in debug mode, and i clicked on “Script debugging” => “Enabled”. Maybe worth to mention.

          Thanks for bringing this to our attention, Guillaume! Blazor WebAssembly debugging is based on the script debugging infrastructure. I’ll follow up to make sure this is well documented.

  • Micah Rairdon 0

    Hi is there a way to subscribe to these release notes like an RSS feed or something?

  • Carlos Villegas 0

    Hello there,

    After upgrading my Blazor WASM preview 2 application to preview 3 the only thing from this post that’s not working is the Auto-rebuild feature. I’m using Visual Studio 2019 16.6 Preview 2 and debugging using the .NET Core runtime instead of IIS Express. My solution has 3 projects, the client, server and the shared library, but VS won’t auto-rebuild, not matter what file I change.

    Do I need to turn something else on?


    • Daniel RothMicrosoft employee 0

      Hi Carlos. For auto-rebuild to work two things are required: 1. Don’t run with the debugger (Ctrl-F5 instead of F5), and 2. Run with IIS Express.

      • Palo Mraz 0

        Hi Daniel, I would suggest to put these two prerequisities right in the blog post; they aren’t obious at all…

        • Daniel RothMicrosoft employee 0

          Good idea! Done.

  • Damien Delaire 0

    Will Blazor WebAssembly support playing hls m3u8 file format?

  • Maziar Ghafouri 0

    Deep objects not showing in the Locals, I have problems debugging deep objects.

    • Daniel RothMicrosoft employee 0

      Hi Maziar. Thanks for trying out the new debugging support and providing feedback! Could you please open a GitHub issue with more details about the problem you are seeing with deep objects so that we can take a look?:

      • Maziar Ghafouri 0

        Thank you for attention I will create a GitHub issue.

  • Morten Meisler 0

    Any example of using the configuration in program.cs ? Thanks

      • Morten Meisler 0

        ok thanks. Usually you want to pass in authentication settings, like clientid and authority (ex. msal or other identity providers). So would love to have that as well before release 🙂

  • Daniel Bassett 0

    Why is there no Docker Support for the WASM project template?

  • Paul Trotter 0

    I have an interesting issue that started after upgrading to 3.2.0 preview 2, and still exists in preview 3.

    This issue did not happen in preview 1.

    My project will compile and run in Debug mode, but when I do a publish to a folder using the “Release” configuration, it fails with this error:

    1>------ Build started: Project: Marquis.SightGlass.WebAssembly, Configuration: Release Any CPU ------
    1>Fatal error in Mono IL Linker
    1>C:\Users\PaulT\.nuget\packages\\3.2.0-preview3.20168.3\targets\Blazor.MonoRuntime.targets(247,5): error : Unhandled exception. Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'SQLitePCLRaw.core, Version=, Culture=neutral, PublicKeyToken=1488e028ca7ab535'
    1> ---> Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'SQLitePCLRaw.core, Version=, Culture=neutral, PublicKeyToken=1488e028ca7ab535'
    1>   at Mono.Cecil.BaseAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
    1>   at Mono.Linker.AssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
    1>   at Mono.Linker.LinkContext.Resolve(IMetadataScope scope)
    1>   at Mono.Linker.LinkContext.Resolve(IMetadataScope scope)
    1>   at Mono.Linker.LinkContext.ResolveReferences(AssemblyDefinition assembly)
    1>   at Mono.Linker.Steps.LoadReferencesStep.ProcessReferences(AssemblyDefinition assembly)
    1>   at Mono.Linker.Steps.LoadReferencesStep.ProcessAssembly(AssemblyDefinition assembly)
    1>   at Mono.Linker.Steps.BaseStep.Process(LinkContext context)
    1>   at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step)
    1>   at Mono.Linker.Pipeline.Process(LinkContext context)
    1>   at Mono.Linker.Driver.Run(ILogger customLogger)
    1>   at Mono.Linker.Driver.Execute(String[] args, ILogger customLogger)
    1>   at Mono.Linker.Driver.Main(String[] args)
    1>C:\Users\PaulT\.nuget\packages\\3.2.0-preview3.20168.3\targets\Blazor.MonoRuntime.targets(247,5): error : ILLink failed with exit code -532462766.
    1>Done building project "Marquis.SightGlass.WebAssembly.csproj" -- FAILED.
    2>------ Skipped Publish: Project Marquis.SightGlass.WebAssembly, Configuration: Release Any CPU ------
    ========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
    ========== Publish: 0 succeeded, 0 failed, 1 skipped ==========
    • Paul Trotter 0

      Hmm… well I’m not sure what the issue was, but I copied all of my code into the new version of the template and things seem to be working now. Never mind!

Feedback usabilla icon