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

[audacity76]

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

[os-dmi]

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.

[mono-wallace]

I encountered the same issue after upgrading to .NET 9! It was resolved after I deleted the browser's cache storage. I also noticed that the cache storage keys for .NET 8 and .NET 9 are different.

I have run into the exact same issue when updating our test environments. Warnings and errors in the browser console are the same, and I could resolve it by disabling the browser cache. Of course, I can not really ask customers to disable the browser cache on first use after the update. So a proper solution to this issue would be appreciated.

[kir0riwal]

I have run in same problem exact same mentioned by # mono-wallace
After updating Visual studio , framework got updated automatically to 8.0.11 and WASM started breaking.

submitted a question to Microsoft as well which they declared duplicate with existing one -

https://developercommunity.visualstudio.com/t/net-80-Blazor-web-application-dependen/10796757

@github Team - This is still UNRESOLVED. Please provide a solution.

[ericvb]

We have only internal customers, so the trick of deleting the browser cache for the deployed site was not a real problem, not user friendly, but doable.

One problem that was unresolved, was debugging in Visual Studio 2022. Everytime I got the error "TypeError: u.isDebuggingSupported is not a function" when launching a local debug session using IISExpress.
Deleting the cache in Chrome did not do the trick.
As test I switched to use Edge as browser (first time use of Edge as debug browser, so there should not be a cache problem), and the problem was indeed gone.
So it was definitely a cache problem! But why that didn't work in Chrome with deleting all cache?

Finally I found the solution. When launching a debug session I had 3 Chrome browser instances open, one with the webapis backend and 2 with the gui's: localhost:xxxx end localhost:yyyy
I deleted the cache in the first browser screen localhost:xxxx and I deleted the cache in the second browser screen localhost:yyyy.
After relaunching the debug session, no error anymore!

So somewhere Visual Studio 2022 (or IIS Express?) caches something that is linked to the used port.
I found a related problem about this: https://developercommunity.visualstudio.com/t/Problems-with-Visual-Studio-2022-Debuggi/10327641?page=12&pageSize=15&sort=active&topics=visual+studio+2019+version+16.7
But there wasn't really an explanation of the reason or cause

Hopes that this will help some people :-)

[ATEEKGIT]

Started to face exact same issue after upgrade of visual studio to latest version.

After reading all this thread i was wondering how may such posts should be enough for micrsoft bros to take this stuff serious.

[kir0riwal]

This issue is going on from past 2+ months and not one from Microsoft is responding on this ..

Javier Calvarro Nelson - Since this issue is assignee to you, do you have any SLA to get it resolved and if you could not resolve it the ESCALATE this to higher management.

Do we have to write to Satya Nadela then Microsoft team would respond on this ? Atleast keep all the stakeholders UPDATED with latest what is going on to get this issue RESOLVED.

submitted a question to Microsoft as well which they declared duplicate with existing one -

https://developercommunity.visualstudio.com/t/net-80-Blazor-web-application-dependen/10796757

Similar way @Artak Mkrtchyan [MSFT] declared above mentioned issue as duplicate and after that no update. WHY microsoft team is NOT responding ? WHY you guys keeping silent on this? Can you redirect us to your Manager or schedule a CALL to discuss on this. Please understand the INTENCITY of this issue impacting thousand of users by now.

https://github.com/github Team - This is still UNRESOLVED. Please provide a solution.

[kir0riwal]

I encountered the same issue after upgrading to .NET 9! It was resolved after I deleted the browser's cache storage. I also noticed that the cache storage keys for .NET 8 and .NET 9 are different.

I have run into the exact same issue when updating our test environments. Warnings and errors in the browser console are the same, and I could resolve it by disabling the browser cache. Of course, I can not really ask customers to disable the browser cache on first use after the update. So a proper solution to this issue would be appreciated.

Have you published latest code in Rancher and then while trying to access what is error ?

This issue has nothing to do with Browser cache, it is something to do with Blazor.Web.Assembly file.

[monsieurvor]

pls fix

Meanwhile, as a temporary work-around to prevent users having to hard refresh our deployed standalone WASM app, we did the following:

• Set all AspNetCore-related packages to <=8.0.8
• Use docker base image mcr.microsoft.com/dotnet/sdk:8.0.402
• Disabled wasm-tools workload, as it seems to pull-in the latest run-time

[kir0riwal]

Thanks Monsieurvor for your response, could you share details about this particular step how to achieve it ?

Meanwhile, as a temporary work-around to prevent users having to hard refresh our deployed standalone WASM app, we did the following:

Set all AspNetCore-related packages to <=8.0.8
Use docker base image mcr.microsoft.com/dotnet/sdk:8.0.402
Disabled wasm-tools workload, as it seems to pull-in the latest run-time -> How you did it or what is the process or code to disable wasm-tool workload ? Please share.

Appreciate your help on this..!!

[monsieurvor]

Thanks Monsieurvor for your response, could you share details about this particular step how to achieve it ?

Meanwhile, as a temporary work-around to prevent users having to hard refresh our deployed standalone WASM app, we did the following:

Set all AspNetCore-related packages to <=8.0.8 Use docker base image mcr.microsoft.com/dotnet/sdk:8.0.402 Disabled wasm-tools workload, as it seems to pull-in the latest run-time -> How you did it or what is the process or code to disable wasm-tool workload ? Please share.

Appreciate your help on this..!!

It was simple as commenting out this line #RUN dotnet workload install wasm-tools in our Dockerfile.

It's an optional step, and you might lose some app optimizations, but at least it works, lol.

After deployment, you can verify the runtime version in browser devtools -> Sources -> _framework -> dotnet.runtime.8.0.8.9z6kkxsnez.js

[gmeister99]

Has anyone resolved the .NET9 upgrade issue (as many have noted above), or are we patiently waiting for 9.0.1 runtime release?

[ATEEKGIT]

probably silense of ms guys means alot to understand that core runtime javascript versions are changed and already cached scripts in browser clients will be required to clear in any case and they don't have any tangible solution to this problem in their hand so far.

though having larger bases of external customers will badly impact for people who are using blazor webassembly.

[marius-i-marin]

Here's a workaround that worked for me:

<script src="_framework/blazor.web.js" autostart="false"></script>
<script>
    Blazor.start({ webAssembly: {
        loadBootResource: function (type, name, defaultUri, integrity)
        {
            if (defaultUri == "_framework/dotnet.js")
            {
                return "_framework/dotnet.js?v=1";
            }
        }
    } } );
</script>

[kir0riwal]

@marius-i-marin
Marius Marin - did you added this code in "INDEX.CSHTML" ? or could to share where exactly in which file you made this code change in your web application solution ?

[kir0riwal]

@javiercn - Since this issue is assigned to you . are you working for MICROSOFT ? and is there any one also working in your team to get this RESOLVED ?

What SEVERITY Microsoft has acknowledged this issue and could you share your approach to fix this ISSUE?
Why no-one from Microsoft responding , do you have any set SLA for such issue ? or could you share where or whom we need to contact in order to get this issue fixed ? Business is getting IMPACTED due to this unresolved bug.

[marius-i-marin]

@kir0riwal
I added my workaround in Components/App.razor file.
(see https://learn.microsoft.com/en-us/aspnet/core/blazor/fundamentals/startup?view=aspnetcore-9.0#load-client-side-boot-resources)

[kir0riwal]

@marius-i-marin

one question on this, did you kept this statement in "Index.html" file like this or where do you have this statement ?

<script> src="_framework/blazor.webassembly.js"> </script or you updated this statement also with autostart = false , like this - <script> src="_framework/blazor.webassembly.js" autostart="false"> </script please share ...

[neseih]

You could try another solution:
Might not work if files are already cached.
Add this code before app.UseRouting()

// Set up custom content types - associating file extension to MIME type

var provider = new FileExtensionContentTypeProvider();

// Add new mappings

provider.Mappings.Add(".properties", "application/octet-stream");

var options = new StaticFileOptions
{
    
  // maybe this is not necessary
  ContentTypeProvider = provider,
   
  // fix for cached dotnetjs integration check fails. Always ask server about version.
    
  OnPrepareResponse = (r) => {
                            
    if (r.File.Name.StartsWith("dotnet") && r.File.Name.EndsWith(".js")) {
                                   
       r.Context.Response.Headers.Append("cache-control", "max-age=0");
                            
    }
                       
 }

};


app.UseStaticFiles(options);

[ElliottBrand]

I believe this issue is resolved by one of these two approaches (or both).

1. Delete all the obj & bin folders from your solution, then rebuild and re-deploy if you aren't using a CICD pipeline. If you aren't using a CICD pipeline, you may be publishing some outdated artifacts that could cause problems, or you may even experience issues in local development.
2. I believe Implementing a cache buster should solve the caching issues, but it's important to understand what's happening before pasting in a change. When a browser loads static resources like JavaScript files or CSS files, it typically caches them based on their URL to speed up subsequent loads. However, since it treats each unique URL as a different resource, when you set a query parameter on the URL to that resource and change it, the browser should reload it. If you look in the Network tab in the browser tools, you'll notice that it's showing a 304 status code (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304) for that file when it's cached and a 200 status code when it reloads with a URL that isn't cached.

Blazor WebAssembly Example:
<script src="_framework/blazor.webassembly.js?cb=123456"></script>

Blazor Server Example:
<script src="/_framework/blazor.server.js?cb=123456"></script>

Blazor (the newer approach in App.razor) Example:
<script src="_framework/blazor.web.js?cb=123456"></script>

If implementing a cache buster approach like this, you just need to decide how you want to render the unique string in the query parameter. You could simply update it manually with every release, but you'll probably want to do it programmatically. You'll need to decide what works best for your application. Some people set it by their app version (when the app is versioned), some set it by DateTime Ticks, etc.

[marius-i-marin]

@ElliottBrand
Implementing the cache buster on blazor.web.js doesn't work for me, as the problem is caused by the loading of an old cached version of dotnet.js.

@kir0riwal
Here's my app.razor file:
App.razor.txt
My project is built from the newer "Blazor Web App" project template, so it uses "_framework/blazor.web.js" (instead of "_framework/blazor.webassembly.js").

[JeroMiya]

We are no longer able to reproduce this issue, though likely this is due to all existing caches expiring. We set the cache control header on all outgoing static file middleware served files to no-cache. This is slightly less efficient, but the extra 302 request/response overhead is acceptable as our application is not extremely high volume and there doesn't exist an automatic file hashing mechanism for js modules loaded at runtime (such a mechanism would likely need a source generator to read the content of bundled js modules, compute a hash, and inject the hash into the file name we pass to the JS interop when loading modules - not something in scope for this project).

[kir0riwal]

@JeroMiya - could you share how you implemented the cache control header?

I tried with all the way outs mentioned in above notifications, but none of them worked out for us.

[pauldavis-dwe]

After many hours of investigation to possible work-arounds I FINALLY have something working!
NOTE: This works for us because we have an MVC app that loads first and takes users over to the Blazor app.

We removed <RuntimeFrameworkVersion>8.0.8</RuntimeFrameworkVersion> from the .csproj file and added the following JavaScript into the MVC app layout CSHTML file:

let xhr = new XMLHttpRequest();

xhr.open('GET', '/b/_framework/dotnet.js');

xhr.setRequestHeader('Cache-Control', 'no-cache, no-store, max-age=0');
xhr.setRequestHeader('Expires', 'Thu, 1 Jan 1970 00:00:00 GMT');
xhr.setRequestHeader('Pragma', 'no-cache');

xhr.send();

That seems to inform the browser that the cached v8.0.8 dotnet.js file should be deleted as when I then load any Blazor URL the browser correctly requests the v8.0.11 version of the file!

I will add that this should NOT be necessary! The team that removed the hasDebuggingEnabled property and added the isDebuggingSupported should have considered the fact that it was a BREAKING change and left backwards compatibility.

[Bellarmine-Head]

If the user clicks the button to (hard) refresh the page it works again, so it's not a persistent issue. But in my opinion this is very bad user experience for an out-of-the-box configuration of Blazor WASM.

Damn straight! Our CTO took the executive decision in May 2020 - when I adopted Blazor WebAssembly - to restrict it to internal tools, and to never allow it for our public-facing web apps. What a wise decision that was, given this and related issues.

Telling my internal users to Ctrl+F5 (or hard refresh by some other means) just because the framework version got updated is embarrassing enough.

More awful on a day-to-day basis is the failure to launch VS 2022 Pro to debug my web app - just because the framework version changed. Today I wasted hours of my life after upgrading my .NET 8 solution to 9:- endless errors relating to failing to load obscure files like "promise-controller.ts" etc after hitting F5. When I finally got .NET 9 to work with VS 2022 + Edge, I decided to go back to .NET 8... and spent more hours fighting to make that work! This really shouldn't be happening.

I never had a problem with Blazor WebAssembly prior to .NET 8 - except for the Razor editor being a bit rubbish. That's improved, but can still really annoy you by doing really dumb stuff.

The fact that problems large and small appeared on the release of .NET 8 (or soon after) and still aren't resolved today (over a year later, and with the release of .NET 9) is extremely concerning.

At this time, I worry whether these problems will even be resolved by the time of .NET 10 release. For this reason, I'm wouldn't recommend Blazor WebAssembly to any new adopter. But I don't need to worry about there being new adopters, as Microsoft went and made it very difficult for anyone new adopting it by:-

• "improving" the new-project template so that it fails to generate a proper Client, Server, Shared solution structure
• having the Client code fake the loading of the weather data from the server by generating it locally, and thus not showing new users how to load data from the Server (and not indicating that shared model classes are a thing in the first place)
• ignoring / backlogging calls to correct this appalling situation

I love Blazor WebAssembly, but I'm concerned for its future for all of these reasons and more.

[kir0riwal]

After many hours of investigation to possible work-arounds I FINALLY have something working! NOTE: This works for us because we have an MVC app that loads first and takes users over to the Blazor app.

We removed <RuntimeFrameworkVersion>8.0.8</RuntimeFrameworkVersion> from the .csproj file and added the following JavaScript into the MVC app layout CSHTML file:

let xhr = new XMLHttpRequest();

xhr.open('GET', '/b/_framework/dotnet.js');

xhr.setRequestHeader('Cache-Control', 'no-cache, no-store, max-age=0');
xhr.setRequestHeader('Expires', 'Thu, 1 Jan 1970 00:00:00 GMT');
xhr.setRequestHeader('Pragma', 'no-cache');

xhr.send();

That seems to inform the browser that the cached v8.0.8 dotnet.js file should be deleted as when I then load any Blazor URL the browser correctly requests the v8.0.11 version of the file!

I will add that this should NOT be necessary! The team that removed the hasDebuggingEnabled property and added the isDebuggingSupported should have considered the fact that it was a BREAKING change and left backwards compatibility.

@pauldavis-dwe
Do you have an idea about how this solution could be implemented for Blazor webassembly application which is written in .NET 5 initially and then migrated to 6 and finally to 8.0 ?

If possible can you share app layout CSHTML file, how did you implemented in there ?
Because my application is blazor web assembly , so I have Index.HTML file . I was curious if I could use it there or how exactly you implemented it ?

---

let xhr = new XMLHttpRequest();

xhr.open('GET', '/b/_framework/dotnet.js');

xhr.setRequestHeader('Cache-Control', 'no-cache, no-store, max-age=0');
xhr.setRequestHeader('Expires', 'Thu, 1 Jan 1970 00:00:00 GMT');
xhr.setRequestHeader('Pragma', 'no-cache');

xhr.send();

---

Appreciate any details on this , if possible ...

[windofny1]

If you are using asp.core for hosting Blazor Web Assembly, then you can use this code in program.cs asp. core project:

app.UseStaticFiles(new StaticFileOptions()
{
    OnPrepareResponse = context =>
    {       
        context.Context.Response.Headers["Clear-Site-Data"] = @"""cache"", ""cookies"", ""storage"", ""executionContexts""";
    }
});

In this case all responses from server will be reloaded. But it must be used only with parameters, first time load after update for user.

[nasat-w]

This solution worked for me. I used this to clear the cache locally once and commented out. Sorry. By mistake, I thumbed down and not able to change.

app.UseStaticFiles(new StaticFileOptions()
{
OnPrepareResponse = context =>
{
context.Context.Response.Headers["Clear-Site-Data"] = @"""cache"", ""cookies"", ""storage"", ""executionContexts""";
}
});

[damien7792]

We have been facing this issue for a couple months. We have read this thread, but none of the solutions worked for us.
So I just want to add a comment if anyone find themselves in our situation.

We are observing this issue it on our web servers only, not locally. Our app is built and deployed through an Azure DevOps pipeline. We've tried upgrading the wasm nuget packages, downgrading them. We tried clearing the cache, etc. Nothing worked.

The "clean your obj and bin folders" in Visual Studio made little sense for us since we're building in Azure DevOps.
Until we realized ... that maybe we need to clean up those build folders in ADO.

And indeed, changing the "Clean" option from "Sources" to "All Build Directories" finally fixed the issue

Hope that helps