`dotnet.js` cache busting (fingerprinting), Symptom: Cannot read properties of undefined (reading 'out')

[hakenr]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When upgrading from 8.0.4 to 8.0.5, the dotnet.js changed.
In opposite to dotnet.native.{fingerprint}.js and dotnet.runtime.{fingerprint}.js, the dotnet.js is not fingerprinted and thus cached. The usual Clear site data in F12-DevTools do not help as the file is cached by the browser and still taken from "(disk cache)".

The 8.0.4 dotnet.js is not compatible with 8.0.5 dotnet.native.{...}.js or dotnet.runtime.{...}.js and the symptom is:

logging.ts:32  MONO_WASM: TypeError: Cannot read properties of undefined (reading 'out')
    at $l (https://localhost:44303/_framework/dotnet.runtime.8.0.5.gongq8hbow.js:3:198913)
    at ze (https://localhost:44303/_framework/dotnet.js:3:30895)
    at https://localhost:44303/_framework/dotnet.js:3:30131
    at async Object.create (https://localhost:44303/_framework/dotnet.js:3:34510)
    at async https://localhost:44303/_framework/blazor.web.js:1:154483
    at async https://localhost:44303/_framework/blazor.web.js:1:164313

startup.ts:43  Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'out')
    at $l (startup.ts:43:17)
    at ze (run.ts:461:11)
    at run.ts:505:11
    at async Object.create (run.ts:361:72)
    at async blazor.web.js:1:154483
    at async blazor.web.js:1:164313

(No module parameter set when calling configureRuntimeStartup() from initializeModules().)

Expected Behavior

dotnet.js to be correctly fingerprinted (As it already used to be before splitting to several files?).

Steps To Reproduce

VS 2022 17.9.6 - Create new BWA - WebAssembly project + run locally in browser.
Update VS to 17.9.7 (brings dotnet 8.0.5).
Run the same project again.

Exceptions (if any)

No response

.NET Version

8.0.5 (9.0.0-preview3 still does not resolve this issue)

Anything else?

WORKAROUND: Ctrl+F5 in browser to force reloading the file.

(It seems this is already in progress, as there are some options in tests which enable checking the fingerprinting on dotnet.js.)

[hakenr]

Related:

• Blazor AOT Cache Busting sdk#20630
• 4a2f9d3

Failing lines of code:

• runtime/src/mono/browser/runtime/startup.ts

  Line 39 in 19467dc

  if (!module.out) {

• runtime/src/mono/browser/runtime/loader/run.ts

  Line 445 in 1f08a36

  await configureRuntimeStartup(emscriptenModule);

[lewing]

cc @pavelsavara

[pavelsavara]

perhaps we could somehow attach build timestamp in the blazor code
https://github.com/dotnet/aspnetcore/blob/c91ce3d2601394242866e7beae2b2339ced3a5d9/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts#L119-L131

something like import('_framework/dotnet.js?version=' + buildId)

The other option is to bundle dotnet.js inside blazor's JS file. Assuming that it doesn't have the same issue.

cc @maraf @javiercn

[maraf]

There is a guidance about hosting and upgrading blazor apps dotnet/aspnetcore#52022 (the title mentions "major" upgrade, but in reality the situation can happen even with servicing release).

The situation will be better for hosted mode in .NET 9 thanks to dotnet/sdk#39405 and dotnet/sdk#39636.

For standalone mode ideally we should be fingerprinting everything (blazor.js, dotnet.js, all dlls/wasms, but also scripts and styles from nuget packages). But that requires rewriting code that references those files. Unlike for webpack and similar we don't have tooling to do it safely. We should review again if we can it do for the most typical scenarios

The other option is to bundle dotnet.js inside blazor's JS file. Assuming that it doesn't have the same issue.

This is unfortunately just about moving the problem to a different file

[TomGathercole]

Is there any way we can manually introduce any extra cache-busting? Ctrl+F5 is an obvious solution, but many of our customers are non-technical and they'll end up having to raise a support ticket with us to find that out.

For unrelated reasons we have to adopt patch releases of dotnet very quickly, and I'd rather avoid causing our customers grief a bunch more times before .NET 9 releases.