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 https://blazor.net.

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 https://mycdn.example.com/blazorwebassembly/3.2.0-rc1/, then you could configure your application to use those resources as follows:

<script src="_framework/blazor.webassembly.js" autostart="false"></script>
<script>
    Blazor.start({
        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
        }
    });
</script>

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>
<script>
    Blazor.start({
        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' }
            });
        }
    });
</script>

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.

Feedback

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!

91 comments

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

  • Stéphane Roy 0

    Hi,

    We have some integrity issues when using our on premise (not cloud based) Azure DevOps Server pipelines. The integrity issue is only with the DLLs.

    As an example

    bmatdvapp01/:1 Failed to find a valid digest in the 'integrity' attribute for resource 'http://bmatdvapp01:9999/_framework/_bin/Microsoft.AspNetCore.Components.dll' with computed SHA-256 integrity 'kwoDgECNJZ7WsqNcdPn3b33Ddftu8YEd+tvwHS4WrsI='. The resource has been blocked.

    Please see also Blazor WebAssembly 3.2.0 breaks integrity of DLLs

    A Visual Studio publish is fine on my local machine (although we did not test the access from another machine). Also accessing “locally” from the server to which we have deployed (using the pipelines) is fine. I even tried to use the same options when doing the publish from VS, i.e. “runtime Portable” which seemed to be the only big difference.

    Here’s the YAML for the build pipeline. We use the template “IIS website deployment” for the release pipeline.

    pool:
      name: Default
      demands: Cmd
    
    steps:
    - task: NuGetToolInstaller@1
      displayName: 'Use NuGet '
      inputs:
        checkLatest: true
    
    - task: NuGetCommand@2
      displayName: 'NuGet restore'
      inputs:
        restoreSolution: FichePompageUI/FichePompageUI.sln
        feedsToUse: config
        nugetConfigPath: FichePompageUI/NuGet.Config
    
    - task: BatchScript@1
      displayName: 'Rename pipelineRelease_Web.config to Web.config'
      inputs:
        filename: 'FichePompageUI\renameConfig.cmd'
    
    - task: DotNetCoreCLI@2
      displayName: 'dotnet publish Release'
      inputs:
        command: publish
        arguments: '--configuration Release --runtime Portable'
    
    - task: CopyFiles@2
      displayName: 'Copy publish.zip to $(Build.ArtifactStagingDirectory)'
      inputs:
        SourceFolder: '$(System.DefaultWorkingDirectory)'
        Contents: |
         **\publish.zip
         
         
         
        TargetFolder: '$(Build.ArtifactStagingDirectory)'
        CleanTargetFolder: true
        flattenFolders: true
    
    - task: PublishBuildArtifacts@1
      displayName: 'Publish Artifact: FichePompageUIDrop'
      inputs:
        ArtifactName: FichePompageUIDrop
    

    Thanks

    • Stéphane Roy 0

      ** UPDATE **

      Hi,

      I tried to access my deployment done with VS publish from another machine. The issue exists. Does someone know what could be the root cause?

      Thanks

Feedback usabilla icon