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

omni-htg commented 1 day ago

Is there an existing issue for this?

[x] 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 commented 1 day ago

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

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

javiercn commented 1 day ago

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

javiercn commented 1 day ago

@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 commented 1 day ago

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 :)

audacity76 commented 21 hours ago

I have the same issue. But I think it is related to the update to Visual Studio 2022 17.11.5!

os-dmi commented 19 hours ago

It is not a Visual Studio issue! I have the exact same error message when creating a build (Ubuntu 20.04). I have also tried using different browsers and the issue persists. The issue appeared with sdk-version 8.0.10

Edit: "Fixed" for now by manually installing sdk version 8.0.8

audacity76 commented 19 hours ago

I haven't upgraded my project to 8.0.10 and I get this issue. But with the visual studio update came an sdk update. I guess that is causing the issue.

audacity76 commented 10 hours ago

I'm using the SDK Version 8.0.403 now and my app works with packages 8.0.8 and 8.0.10.

pontusrekonnect commented 4 hours ago

Experiencing the same issue after doing an upgrade today of latest Visual Studio. The Blazor WASM web app does not "boot" if I am not doing a cache clear like Ctrl+F5 in browser.

KirovAir commented 3 hours ago

On our IIS servers I've fixed the problem using the no-cache directive which seems to fix the issues for our end-users, but it's far from ideal.

<!-- Fix for https://github.com/dotnet/aspnetcore/issues/58313 -->
<location path="_framework/dotnet.js">
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <add name="Cache-Control" value="no-cache" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</location>

hunglng commented 1 hour ago

In our Azure Static Web App, adding following config to staticwebapp.config.json seems to fix the issue for Edge and Chrome but not Firefox. We did not do any update in our local development environment. Seems that the agent in Azure DevOps pipeline has the update.

    {
      "route": "/_framework/dotnet.js",
      "headers": {
        "cache-control": "no-cache"
      }
    },

dotnet / aspnetcore