[Blazor WASM] Upgrading project to .NET 8.0.10 breaks WASM

[omni-htg]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Upon upgrading a Blazor WASM Standalone .NET 8 project to 8.0.10 (including all related NuGet packages), Debugging on Visual Studio 2022 17.11.5 or navigating to a Deployed site with previous version cache breaks during runtime with the following:

MONO_WASM: The version of dotnet.runtime.js is different from the version of dotnet.js!
MONO_WASM: The version of dotnet.native.js is different from the version of dotnet.js!
MONO_WASM: mono_wasm_load_runtime () failed TypeError: u.isDebuggingSupported is not a function
    at Vl (c:\Users\<PATH_TO_SOLUTION>\_framework\https:\raw.githubusercontent.com\dotnet\runtime\81cabf2857a01351e5ab578947c7403a5b128ad1\src\mono\wasm\runtime\startup.ts:575:28)
    at c:\Users\<PATH_TO_SOLUTION>\_framework\https:\raw.githubusercontent.com\dotnet\runtime\81cabf2857a01351e5ab578947c7403a5b128ad1\src\mono\wasm\runtime\startup.ts:551:5
    at https://localhost:7112/_framework/dotnet.runtime.8.0.10.39apnb5yx8.js:3:207329 {stack: 'TypeError: u.isDebuggingSupported is not a fu…/dotnet.runtime.8.0.10.39apnb5yx8.js:3:207329', message: 'u.isDebuggingSupported is not a function'}

MONO_WASM: TypeError: u.isDebuggingSupported is not a function
    at Vl (https://localhost:7112/_framework/dotnet.runtime.8.0.10.39apnb5yx8.js:3:217167)
    at https://localhost:7112/_framework/dotnet.runtime.8.0.10.39apnb5yx8.js:3:206677
    at https://localhost:7112/_framework/dotnet.runtime.8.0.10.39apnb5yx8.js:3:207329
TypeError: u.isDebuggingSupported is not a function
Stack trace:
 >  at Vl (https://localhost:7112/_framework/dotnet.runtime.8.0.10.39apnb5yx8.js:3:217167)
 >    at https://localhost:7112/_framework/dotnet.runtime.8.0.10.39apnb5yx8.js:3:206677
 >    at https://localhost:7112/_framework/dotnet.runtime.8.0.10.39apnb5yx8.js:3:207329

Previous issues related to that version difference message recommended clearing out all bin and obj folder -- which I have tried with no success.

One of our users reported the same errors on their Chrome / Edge console, for which clearing out their browser cache made it work.
It seems that there might be some sort of incompatibility somewhere that "breaks" instead of "upgrading" the .NET libraries -- so it looks like the issue comes from the moving from one version to the next, not 8.0.10 by itself.

If this is the case, where just by navigating to the site without a "clean cache" it breaks, then it's a bigger regression than I expected.
Hopefully it's not!

Thanks for your time.

Expected Behavior

On VS 2022, debugging should just work flawlessly.
On deployed site, users should NOT be expected to clear their cache to navigate to the site.

Steps To Reproduce

From a Standalone Blazor WASM project starting on 8.0.8, compile and debug. Then, upgrade to 8.0.10 and try again.

On a deployed site, deploy the 8.0.8 version and navigate to it. Then, deploy the 8.0.10 version and with the same browser with the site cached, navigate to the site.

Exceptions (if any)

Clearing cache, or navigating with a "fresh" browser works fine.

.NET Version

8.0.403

Anything else?

.NET 8.0.10 / 8.0.403
Visual Studio 2022 17.11.5

dotnet --info:
.NET SDK:
Version: 8.0.403
Commit: c64aa40a71
Workload version: 8.0.400-manifests.e99c892e
MSBuild version: 17.11.9+a69bbaaf5

[omni-htg]

Tagging related issues, including those in /dotnet/runtime:

• Hosted Blazor Web App throws error when opening (invalid cache?) #54285
• dotnet.js cache busting (fingerprinting), Symptom: Cannot read properties of undefined (reading 'out') runtime#102272

Apologies if the report should be handled on the /dotnet/runtime side of things, please indicate so.

[javiercn]

@maraf is this the same issue we had a while back?

[javiercn]

@omni-htg you can try adding a Cache: no-cache to the response for the JS files or do a hard refresh to see if the issue goes away.

[omni-htg]

Hey @javiercn, here's some updates on what I could find:

• Locally on my VS 2022 I have tried switching the port assigned so that it gets treated as a "different site", and that worked!
• When working with the original port, I cannot for the life of me find where or how to clear whatever is cached under that original port / site, as I have manually cleared everything that Chrome offers under "Delete browsing data..." and have pulled our project from scratch to start fresh.
• For the deployed site, in our testing environment, every team member that have had visited the site before (and as such had it cached) experienced the same regression, and needed to have their cache cleared.

This last item is the most critical for us, as we cannot realistically have our customers manually clearing their cache just to be able to visit the site.
What is weird to me is that we have gone through multiple 8.0.x versions without any issues -- so I hope you understand how worrisome it is for next versions.

Apologies for the rant-y tone -- now for the provided proposal:
You're suggesting that I add a Cache-Control: no-cache response header to the JS files being served, correct?
Let me check it out :)