Product Unit Recommendation On How To Cache Bust Blazor WASM Files

[taylorchasewhite]

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:

• Blazor WebAssembly - very aggressive caching #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 dotnet/AspNetCore.Docs#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 contacting us.

The behavior you are describing is the standard behavior of PWAs.

• Your app loads, a service worker gets installed.
• The next few times you visit the page, the service worker is active and handles serving the files.
• You then deploy a new version.
• The next time you visit the page, the current service worker is still active and the page is served.
• The browser detects that there is a new service worker available and downloads the new version in the background.
• The next time you visit the page, the new service worker takes control of the page and takes over.

You can check more details here

Our guidance is that the service worker in the app is working as expected and that if that behavior doesn't match your expectations you might be able to change the code in the service-worker.js file in your project or avoid using a service worker at all.

[taylorchasewhite]

Hey Javier, thanks for the quick response. Unfortunately this does not answer the question I have. For the following reasons:

1. I'm asking what the recommended/correct way to bust caching in Blazor WASM is. (Regardless if it is a PWA or not. I only mention that my project is a PWA in case that impacts the cache busting behavior in a Blazor WASM solution that's not a PWA). This response doesn't describe the recommended way to cache bust the DLLs when publishing a new deployment.
2. I'm not seeing the cache be busted at all. Unless I hard refresh via Ctl+Shift+R, I see the same DLLs after more than 24 hours of pushing the new deployment. Even if I did see the browser eventually stop caching the old DLLs/WASM code, I'd want it to detect that immediately so that the users don't get errors from using the old cached DLLs.

Basically if I had to sum up the question above, it would be:

• Is there a version number we should be putting in our client project, or somewhere that automatically busts the browser cache?
• Is there some other .NET Core recommended approach?

And is there a write up of what that approach is.

[taylorchasewhite]

Also regarding this:

Our guidance is that the service worker in the app is working as expected and that if that behavior doesn't match your expectations you might be able to change the code in the service-worker.js file in your project or avoid using a service worker at all.

Does this mean if we remove the service worker, that there is some built-in (obfuscated) functionality that would bust cache after a project has been published again? Is there a description of how this works?

[taylorchasewhite]

I found a good writeup here, which talks about the cacheName coming from the version on <ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>, but when I look at that version number, I don't see how that's related to anything in the project, or what might cause that version to be modified:

.

I haven't yet verified/tested to see if that version changes on every publish or is somehow derived on other data from the project that we should be modifying, like a version number.

Overall it sounds like from that article above (and to an extent your comments above) that PWA might not be great if we want to ensure that a client is up to date.

How does this work if you are using Blazor WASM without a PWA/Service Worker?

Thanks again--

[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.

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.