Blazor: Updating from 8.0.4 to 8.0.5 silently crashed our webapp due to caching of dotnet.js

[vladimir-angelov-1337]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

We have a Blazor application that we are building with the docker image of the SDK targetting 8.0
This caused the docker image to silently change from 8.0.4 to 8.0.5 and our application stopped working unexpectedly, with console errors.

Upon further inspection we found out about the change.

dotnet.native.8.0.4.uy5lxmc247.js
dotnet.runtime.8.0.4.riehddozk1.js

Were changed to:

dotnet.native.8.0.5.noy87qpmp4.js
dotnet.runtime.8.0.5.s4tpo9pkiw.js

Which is fine. However the dotnet.js file was also changed, but due to lacking versioning and a hash, the browser still loaded the previously cached version and it would break the web application until we clear cache and allow for the new dotnet.js to load.

Expected Behavior

No response

Steps To Reproduce

No response

Exceptions (if any)

MONO_WASM: TypeError: Cannot read properties of undefined (reading 'out')
    at $l (https://staging.sbxcars.com/_framework/dotnet.runtime.8.0.5.s4tpo9pkiw.js:3:198913)
    at ze (https://staging.sbxcars.com/_framework/dotnet.js:3:30895)
    at https://staging.sbxcars.com/_framework/dotnet.js:3:30131
    at async Object.create (https://staging.sbxcars.com/_framework/dotnet.js:3:34510)
    at async https://staging.sbxcars.com/_framework/blazor.webassembly.js:1:43178
    at async https://staging.sbxcars.com/_framework/blazor.webassembly.js:1:57722
    at async hn (https://staging.sbxcars.com/_framework/blazor.webassembly.js:1:57325)
u @ dotnet.js:3
dotnet.js:3 Error in mono_download_assets: TypeError: Cannot read properties of undefined (reading 'out')
Q @ dotnet.js:3
10dotnet.runtime.8.0.5.s4tpo9pkiw.js:3 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'out')
    at $l (dotnet.runtime.8.0.5.s4tpo9pkiw.js:3:198913)
    at ze (dotnet.js:3:30895)
    at dotnet.js:3:30131
    at async Object.create (dotnet.js:3:34510)
    at async blazor.webassembly.js:1:43178
    at async blazor.webassembly.js:1:57722
    at async hn (blazor.webassembly.js:1:57325)
blazor.webassembly.js:1 Uncaught (in promise) Error: Failed to start platform. Reason: TypeError: Cannot read properties of undefined (reading 'out')
    at hn (blazor.webassembly.js:1:57366)

.NET Version

8.0.5

Anything else?

No response

[vladimir-angelov-1337]

We see no way to pin 8.0.5 in our build pipeline, so we are working around this by disabling cache for dotnet.js, but that seems unwise.

[halter73]

Which is fine. However the dotnet.js file was also changed, but due to lacking versioning and a hash, the browser still loaded the previously cached version and it would break the web application until we clear cache and allow for the new dotnet.js to load.

This seems related to dotnet/runtime#102272. @lewing Do you have any ideas on how we can avoid this in future servicing updates? In .NET 9, we hope that @javiercn's improvements will avoid over caching.

We see no way to pin 8.0.5 in our build pipeline, so we are working around this by disabling cache for dotnet.js, but that seems unwise.

Out of curiosity, how did you do this? Custom middleware that sets Cache-Control: no-store? I imagine that would work, but not help clients that have already cached dotnet.js. Modifying importDotnetJs to include a random number in the query string might work for existing clients assuming importDotnetJs isn't cached.

[Bellarmine-Head]

Yup. I got this immediately after installing VS 17.9.7 and updating packages to 8.0.5.

Solution for me was to clear brower's cache of web content. Possibly a hard refresh could have done it.

Happened to me on Chrome, Edge and FF and on two different Windows 10 machines.

I have had to instruct my (internal) users to clear cache similarly. We don't use Blazor WebAssembly for public-facing websites, only internal tools.

[halter73]

Are you calling .UseBlazorFrameworkFiles(); or MapRazorComponents<Host>().AddWebAssemblyRenderMode();? Or are you doing a standalone deployment and publishing to a static file server/CDN?

[samhouts]

I ran into this with my ASP.NET Core hosted Blazor WASM site, and clearing browser cache does not work in this situation. I had to fully scorch all bin/obj folders and redeploy.

[Bellarmine-Head]

Are you calling .UseBlazorFrameworkFiles(); or MapRazorComponents<Host>().AddWebAssemblyRenderMode();?

The latter.

app.MapRazorComponents<App>()
    .AddInteractiveWebAssemblyRenderMode()
    .AddAdditionalAssemblies(typeof(OutThink.ContentEditorWebsite.Client.Program).Assembly);

Or are you doing a standalone deployment and publishing to a static file server/CDN?

No.

[vladimir-angelov-1337]

Out of curiosity, how did you do this? Custom middleware that sets Cache-Control: no-store? I imagine that would work, but not help clients that have already cached dotnet.js. Modifying importDotnetJs to include a random number in the query string might work for existing clients assuming importDotnetJs isn't cached.

Yeah, we realised this soon after I wrote my comment and found a way to pin 8.0.4 using it's hash. We'll probably resort to manually serving the _framework files so we can change their names, because we do want to move to 8.0.5 due to the security updates.

This seems related to dotnet/runtime#102272. @lewing Do you have any ideas on how we can avoid this in future servicing updates? In .NET 9, we hope that @javiercn's improvements will avoid over caching.

It looks like it's the same problem, maybe we should close this one and move the discussion there?

Separately, I don't understand why we even load 4 separate JavaScript files and a .json. Is there any advantage to this? In my mind it only degrades performance to load 4 separate files instead of 1 single file with a fingerprint?

[maraf]

Add a link to a possible workaround also here dotnet/runtime#102272 (comment)

[ipax77]

I had the same problem. Solution was to delete the bin and obj folders before building and hard refresh (CTRL-F5) the client.
Would it be possible for dotnet build -c Release to always give the same result regardless of what the bin/obj folders contain?

[maraf]

Would it be possible for dotnet build -c Release to always give the same result regardless of what the bin/obj folders contain?

This looks definitely like a bug. MSBuild has a lot of shortcuts to save time then it seems that previous results can be used.

@ipax77 Could you share what your csproj looks like (I'm investigating what is the cause)? If your project is not open source or you don't want to share the content publicly, you can open a ticket on https://developercommunity.visualstudio.com/ and upload an attachment visible only to Microsoft employees.

[ipax77]

@ipax77 Could you share what your csproj looks like (I'm investigating what is the cause)?

Here is my client project file: dsstats.web.Client.csproj

[D3bo]

I ran into this with my ASP.NET Core hosted Blazor WASM site, and clearing browser cache does not work in this situation. I had to fully scorch all bin/obj folders and redeploy.

Thank You this solved for me

[maraf]

If for anybody clearing cache in the browser doesn't help, could you please build/publish from cmd with -bl before deleting bin/obj and share a produced binlog. It would help investigate the build-time issue

[knepe]

#55978 Is there any workaround without having all end users do a hard refresh? This is a pretty nasty bug for apps having alot of users.....

Edit: @maraf workaround above worked for us 👍