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

[omni-htg]

trafficstars

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]

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

• https://github.com/dotnet/aspnetcore/issues/54285
• https://github.com/dotnet/runtime/issues/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 :)

[audacity76]

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

[ghost]

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]

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]

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

[pontusrekonnect]

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]

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]

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"
      }
    },

[donmezhakan]

Hi everybody. I did everything that was said and done here, but it still didn't work. Downgrading to Visual Studio 2022 17.11.4 fixed the problem. My project structure is App.Server and App.Client(BlazorWebAssembly) netsdk 8.0.400 and dll references are 8.0.10, but when I downgrade, debug works. The problem seems to be caused by Visual Studio. I hope they fix it in the next patch.

[dwe-alan]

@mkArtakMSFT I am sorry, but I don't think this can wait until .NET 10 planning. This really needs to be fixed ASAP or at least Blazor developers need to have some sure-fire cache-busting hints to work around it. Website users should not need to know that in order to avoid a blank screen, it's essential to Ctrl+Refresh their browser.

It would be useful if, when these MONO_WASM errors occur, one of the JavaScript scripts could write to the screen, explaining to the user what they need to do (i.e. hard refresh their browser)

These sort of issues pop up regularly. It's not just with the latest version of .NET 8. It's frustrating and embarassing and wastes a lot of time explaining this stuff to customers.

[lukashummel]

Hi everyone, experienced the same issue. As a workaround, the only thing that fixed it for me was specifying the runtime explicitely to a version older than 8.0.10. Add <RuntimeFrameworkVersion>8.0.8</RuntimeFrameworkVersion> in your csproj file and (at least for me) everything works fine. Microsoft should deliver a fix for that.

[lartusi]

.NET 10 Planning??? So more than 1 year to have this fixed!

I have a lot of people all around the world stuck in the load screen just because i've updated the framework This is not acceptable.

[pedroramirezs279]

I experience the same issue after Visual Studio 2022 was updated yesterday to the latest version. Rolling back to the previous version of Visual Studio made the issue disappears.

Thank you for the time in resolving this issue. I hope waiting to release .NET 10 be a joke.

[pwelter34]

I don't believe this is a cache issue. I've purged the cache, hard reloaded, tried on different machines and that doesn't fix the issue.

[dwe-alan]

@pwelter34 What does your Developer Tools / Console Tab show when you reload?

[jfbosch-inversion]

We are experiencing the same thing on our system. It's not really a viable solution to have to tell all our end users to clear their browser cache.

[pwelter34]

@pwelter34 What does your Developer Tools / Console Tab show when you reload?

You can use this project to reproduce the issue. https://github.com/loresoft/Estimatorx

[miklosa]

Dear AspNetCore team, I have experienced the same issue.

After inserting the line indicated in the following image into the Client project’s csproj file, the error disappeared on my side (as a temporary solution).

[Pvxtotal]

Broke on production, all devices and all browsers. Not related to cache

Fixed by adding:

<RuntimeFrameworkVersion>8.0.8</RuntimeFrameworkVersion>

In the .Client project

[daveg1466]

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

[BurkusCat]

I did a small text/content update to my website which. My pipeline uses "https://dot.net/v1/dotnet-install.sh" to install .NET 8.0 so it presumably downloaded the latest version so I got this error. I've rolled back to an August build of the site to fix the issue.

[JeroMiya]

Also experiencing this issue. I can also verify that the issue is NOT cache related. We were already setting the cache header of all .js files to no-cache prior to experiencing this issue and clearing the cache completely does not make the error go away.

We were able to fix the error by reverting back all the NuGet packages to version 8.0.8 and adding the <RuntimeFrameworkVersion>8.0.8</RuntimeFrameworkVersion> element to the .Client project.

[pingu2k4]

Same issue here. Also appears not to be a cache issue. No amount of cache busting / clearing my cache etc could resolve this - only reverting to an older runtime framework version, as others have pointed out above.

[BusterIT]

I was not able to downgrade or throwing the 8.0.10 js framework references completely out of my build pipeline.

So I did this hack and it solved the issues at customers side (in index.html or some startup js file):

[ElliottBrand]

I also ran into issues after upgrading Visual Studio / .Net and saw the same errors about u.IsDebuggingSupported for the WASM client. After clearing all caches didn't work, I deleted all the obj and bin folders, then redeployed and that resolved it.

[Rauce]

I'm seeing the same issue since upping my Blazor WASM web app to .NET 8.0.10.

Local development works fine – it only happens for me in Production (which deploys via a GitHub Actions process that pulls the repo into a fresh container, builds from scratch, and publishes).

I've had to roll back to 8.0.8 for now.

[jalpuim]

we also had this exact issue only in prod (ran fine in test environments) -- turns out our CDN was caching an old version of dotnet.js which led to a mismatch in versions pulled by the bootstrapper and some breaking change to crash the website. prod starting behaving once we successfully purged the cache (remember to consider all layers, e.g. local, CDN, firewall, etc) for dotnet.js in our CDN.