Product Unit Recommendation On How To Cache Bust Blazor WASM Files

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When I publish my Blazor WASM project, the old client side DLLs are cached, and the cache does not seem to be busted. I have scanned through a few examples/issues/documents looking for the correct approach to accomplish busting the caches on new publishes, including:

• #29095
• Host and deploy ASP.NET Core Blazor WebAssembly
• URL Rewriting Middleware
• Bypass HTTP browser cache when using HttpClient in Blazor WebAssembly
• Cache Busting in Blazor WASM

But I’m still unsure what the “correct”/“recommended” route is here. I suggested adding this to the Host and deploy ASP.NET Core Blazor WebAssembly document, and was referred here to request the recommendation from the product unit.

What is the “correct”/“expected” approach to bust cache for Blazor WASM projects? Please also note this information may be / is likely out there somewhere, but I have not yet figured out where (though I have spent significant time researching).

cc: @guardrex https://github.com/dotnet/AspNetCore.Docs/issues/24748

Expected Behavior

When deploying a new publish of a project, somehow indicate to client browsers to redownload the DLLs/runtime code.

Steps To Reproduce

1. Create the default Blazor WASM project using the current 6.0.0 templates. I’m using Identity Hosted and set the project as a PWA.
2. Publish & deploy it (by any means, I’m deploying to AWS using Docker containers).
3. Make a change to Counter.razor (make it count by 2 or something).
4. Publish & deploy once more.
5. Visit your site. See that the client side component is cached, and clicking the Counter button, that the count still goes up by 1, not 2. Once a “hard refresh” has been done (Ctl+Shift+F) then the counter will grow by 2 on each click.

Exceptions (if any)

No response

.NET Version

6.0.0

Anything else?

No response

[javiercn]

@taylorchasewhite thanks for the additional details.

You can check here how the bootstrapping process works in detail, but in essence is as follows:

• We download an uncached version of blazor.boot.json (as in we tell the browser to bypass any cache, but you should check in case you have some other forms of intermediate caching layers in CDNs and the like).
• blazor.boot.json contains a list of dlls and their hashes. We compare each dll against our own cache and if the hashes match we use the cached version. Otherwise we request the file from the server (checking again against the hash for integrity validation and generating an error if the downloaded file doesn’t match (technically the browser does generate the error)).

The only way the app might fail to update is if you have some intermediate caching layer incorrectly configured and the entire set of files is being cached. Otherwise, the most common error we’ve seen is an incorrectly configured intermediate caching level causing integrity errors during the application load time.

Finally, I would like to finish on a note on PWAs. One of the main goals of a service worker is that your app loads ultra fast and stays available even when the network goes down. As such, is normally better to serve a “stale” version of the app fast rather than loading a new version every time. That said, you can explore some options service-workers offer to get a notification when a new version of a service worker is available and has been successfully installed. You can use that to display a notification on the page to “update to a new version” and reload the page (at which point your users will get the latest version).

Hope this helps.

[msftbot[bot]]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.