Publishing Blazor WASM failing with Integrity checks

[unixbob]

Describe the bug

A newly published Blazor Webassembly .net 5 app fails to start in the browser with Integrity check failures. Have several applications which have run fine on .net5 for months. In the week of .net 6 being released they've started to fail when a new version is published (no idea if it's the .net 6 release, whether it's moving to VS2022, or they're both a coincidence). It's not every single time, but it's now a common issue that has never occurred prior to w/c 8th November 2021.

Developed on Windows 10, Production systems are on Linux behind Nginx. Cleaning the build before publish doesn't fix the problem. Manually deleting the bin and obj folders in the Client and Server Projects makes the problem go away (is probably just the Client project that needs deleting tbh).

To Reproduce

Blazor WebAssembly Self Hosted app on Windows 10, VS2022. Right click on the server project and publish. Publish to a folder, zip up and copy to the Linux server. after starting the app appears to start and then does nothing. But the browser console has the errors shown in the Exception section below. Error log also attached.

With no code changes, no csproj changes, no nuget changes, I can reliably make the problem go away by deleting the bin and obj folders in the projects, performing the steps above and the Blazor app starts.

Exceptions (if any)

app.sharperpages.com/:1 Unknown error occurred while trying to verify integrity.
app.sharperpages.com/:1 Failed to find a valid digest in the 'integrity' attribute for resource 'https://app.sharperpages.com/_framework/HtmlAgilityPack.dll' with computed SHA-256 integrity 'OwW+oeVwPiItyx8Oy+kaasZrJOndOzmKFF6WSddzFFI='. The resource has been blocked.
app.sharperpages.com/:1 Unknown error occurred while trying to verify integrity.
blazor.webassembly.js:1 Error: Failed to start platform. Reason: TypeError: Failed to fetch
at blazor.webassembly.js:1
at blazor.webassembly.js:1
at Object.throw (blazor.webassembly.js:1)
at s (blazor.webassembly.js:1)
d.printErr @ blazor.webassembly.js:1

Further technical details

• ASP.NET Core version:
• The IDE (VS / VS Code/ VS4Mac) you're running on,
• VS Studio 2022 Community Edition on Windows 10
  app.sharperpages.com-1637492813346.log
  and its version:
• Include the output of dotnet --info:

dotnet --info .NET SDK (reflecting any global.json): Version: 6.0.100 Commit: 9e8b04bbff

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19043
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support):
Version: 6.0.0
Commit: 4822e3c3aa

.NET SDKs installed:
5.0.201 [C:\Program Files\dotnet\sdk]
6.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[GerkinDev]

This is happening to us now. What we have changed since the last successful deploy:

• IDE from VS Community 2019 to VS Community 2022 preview
• .Net framework from 5 to 6.

We can confirm that deleting bin & obj fixes the issue.

@PatoElGato

[javiercn]

@unixbob thanks for contacting us.

Please make sure you clean your bin and obj folders after upgrading as some intermediate artifacts might have been left behind in these cases and can cause these issues. Let us know if doing this doesn't fix the issue for you.

@GerkinDev we recommend doing what you did when you upgrade major versions.

[ghost]

Hi @unixbob. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[unixbob]

@unixbob thanks for contacting us.

Please make sure you clean your bin and obj folders after upgrading as some intermediate artifacts might have been left behind in these cases and can cause these issues. Let us know if doing this doesn't fix the issue for you.

@GerkinDev we recommend doing what you did when you upgrade major versions.

This isn't just between upgrading versions though. It's a persistent issue. Am just saying it started around about the time .net6 and / or vs 2022 were released.

I have a manual workaround of manually deleting the bin and obj folders. But more often than not, even after running "Clean Solution" before a publish, I still get this error. The only reliable way to publish the code is now to delete the folders before a publish.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Kazbek]

I had same issue just from updating Grpc libs to next versions. App was already on net6.
Manually delete bin and obj fix this.

Exactly problem was that
wwwroot_framework\Grpc.Core.Api.dll file version 2.41.0.0
wwwroot_framework\Grpc.Core.Api.dll.gz contains 2.40.0.0 version file

[Fabster1993]

For me the solution for this problem was to enforce the server to instruct the browser to not cache "service-worker-assets.js". I could proof, that this file has been cached by browser and then the integrity checks fail, because the defined hashes in asset script are outdated. A possible solution for asp.net core hosted wasm blazor apps could be:

Program.cs:

        _ = app.UseStaticFiles(new StaticFileOptions
        {
            OnPrepareResponse = context =>
            {
                if (context.File.Name == "service-worker-assets.js")
                {
                    context.Context.Response.Headers.Add("Cache-Control", "no-cache, no-store");
                    context.Context.Response.Headers.Add("Expires", "-1");
                }
            }
        });

[dantronik-bugreporting]

I also keep getting these kinda errors intermittently. I created snapshots of both publish directory contents. Not sure if they can be of use.

What would you need from me in order to debug the issue?

[JoelW187]

I've been having the same problem since upgrading to VS2022/.Net 6. Cleaning the bin/obj folders used to work but I've had several deployments recently where cleaning the bin/obj folders did NOT work. In the first instance a couple of weeks ago the problem went away after I updated all my blazor packages to the latest (I think I upgraded from 6.0.2 to 6.0.3). I just had the problem again yesterday and NOTHING worked. I tried completely clean builds straight from source control so there were no outdated files (e.g., blazor.boot.json) but i still got integrity check errors when the blazor framework was loading. The errors only occurred on certain clients, oddly. I finally did a deployment using a DEBUG build and that resolved the problem for now (it's an internal app, thankfully) but that is not a long term solution for obvious reasons. Let me know if there's anything I can provide to help debug this problem as it's very disruptive.

[JoelW187]

Just an update... In my current code the integrity check is failing on System.Private.Xml.Linq.dll which was recently added to the project. I've seen the integrity check issue on other files so it's hard to tell if it's actually file related or something else (like the caching issue described above), but I thought I would point it out in case there is a problem with that specific dll.

[pizzaco]

I'm using dotnet watch run for development. Version 6.0.201.

After making a change to the source code in Client folder, it will automatically build the project. However, the hash for Portal.Client.dll is wrong in [Project Folder]\Client\bin\Debug\net6.0\wwwroot\service-worker-assets.js.

But, the hash is correct in [Project Folder]\Client\bin\Debug\net6.0\wwwroot\_framework\blazor.boot.json.

blazor.boot.json.txt
service-worker-assets.js.txt

If I delete the entire bin folder, service-worker.assests.js is re-created with the correct hash one time. It is wrong for every subsequent change / auto-build until the bin folder is deleted again. The file is being re-created on each auto-build. The hash in service-worker-assets.js always appears to be the value from the previous build.

[smadgerano]

I'm not able to give much technical advice as I'm still learning, but I can say that I'm getting the same errors on deployed material no matter what I try. Anything in the _framework folder seems to fail integrity checks in the browser console. Works everywhere else, will deploy to Azure Static Web Apps just fine, but whem I go to publish on my alternative server, all I get is errors,

I've tried cleaning the bin and obj folders as others have suggested, and trying alternative publish methods, direct from VS, through FileZilla, changing the uplaod type to binary, uploading through the browser to the server etc etc and nothing seems to be working.

[smadgerano]

OK, quick update. After reading a little about how CloudFlare was altering files over their CDN and affecting things in other threads I thought I'd see if there were any compression settings or similar on my server.

I am using a hosting provider that runs the Plesk control panel. I could not see anything regarding compression, but in the "Virtual Directory" page, then clicking on "ASP.NET Configuration" for the root folder, I changed the CAS Trust Level from Full to Medium. and the Authentication mode from Windows to None.

I cleared the cache and refreshed the page and everything kicked in.

I cannot absolutely confirm this was the culprit however, because switching them back to the original settings does not bring the problem back, which is great but useless at proving the theory. Perhaps the change was enough to kick something in on the server and clear a cahced setting somewhere, not sure. Either way things are working.

[rogihee]

@javiercn I added manual version string query to catch this scenario, as explained in #46798. Sometimes we are still bitten by other cache issues with CSS importing other bundled CSS files, but that should be covered by #31922.

[Laftek]

I just found out that I was getting integrity check because blazor.webassembly.js and then .dll files were rejected (403) by Edge (company laptop). This happens when I deploy to netlify. If I deploy to GH it works on my company laptop but only if I use BlazorWasmPreRendering.Build and PublishSPAforGitHubPages nuggets(this one cannot be used for netlify though).

[thekoko89]

I am facing problems with fetching.,
Unknown error occurred while trying to verify integrity.
blazor.webassembly.js:1 TypeError: Failed to fetch
u @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
await in (anonymous) (async)
instantiateWasm @ blazor.webassembly.js:1
mc @ dotnet.7.0.11.s365udhifh.js:5
e.instantiateWasm @ dotnet.7.0.11.s365udhifh.js:5
createWasm @ dotnet.7.0.11.s365udhifh.js:14
(anonymous) @ dotnet.7.0.11.s365udhifh.js:14
(anonymous) @ blazor.webassembly.js:1
await in (anonymous) (async)
start @ blazor.webassembly.js:1
Vt @ blazor.webassembly.js:1
await in Vt (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to fetch
at Ft.loadResourceWithoutCaching (blazor.webassembly.js:1:52219)
at Ft.loadResourceWithCaching (blazor.webassembly.js:1:51950)
loadResourceWithoutCaching @ blazor.webassembly.js:1
loadResourceWithCaching @ blazor.webassembly.js:1
Promise.then (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
start @ blazor.webassembly.js:1
Vt @ blazor.webassembly.js:1
await in Vt (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to fetch
at Ft.loadResourceWithoutCaching (blazor.webassembly.js:1:52219)
at Ft.loadResourceWithCaching (blazor.webassembly.js:1:51950)
loadResourceWithoutCaching @ blazor.webassembly.js:1
loadResourceWithCaching @ blazor.webassembly.js:1
await in loadResourceWithCaching (async)
instantiateWasm @ blazor.webassembly.js:1
mc @ dotnet.7.0.11.s365udhifh.js:5
e.instantiateWasm @ dotnet.7.0.11.s365udhifh.js:5
createWasm @ dotnet.7.0.11.s365udhifh.js:14
(anonymous) @ dotnet.7.0.11.s365udhifh.js:14
(anonymous) @ blazor.webassembly.js:1
await in (anonymous) (async)
start @ blazor.webassembly.js:1
Vt @ blazor.webassembly.js:1
await in Vt (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
Unknown error occurred while trying to verify integrity.
blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to fetch
at Ft.loadResourceWithoutCaching (blazor.webassembly.js:1:52219)
at Ft.loadResourceWithCaching (blazor.webassembly.js:1:51950)
loadResourceWithoutCaching @ blazor.webassembly.js:1
loadResourceWithCaching @ blazor.webassembly.js:1
Promise.then (async)
(anonymous) @ blazor.webassembly.js:1
start @ blazor.webassembly.js:1
Vt @ blazor.webassembly.js:1
await in Vt (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
Unknown error occurred while trying to verify integrity.
blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to fetch
at Ft.loadResourceWithoutCaching (blazor.webassembly.js:1:52219)
at Ft.loadResourceWithCaching (blazor.webassembly.js:1:51950)

On firs load i have error, if i refresh the page it loads normally untill i clear the cache and try to load.
Please help if anyone know

[Kazbek]

I am facing problems with fetching.,
Unknown error occurred while trying to verify integrity.
blazor.webassembly.js:1 TypeError: Failed to fetch
u @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
await in (anonymous) (async)
instantiateWasm @ blazor.webassembly.js:1
mc @ dotnet.7.0.11.s365udhifh.js:5
e.instantiateWasm @ dotnet.7.0.11.s365udhifh.js:5
createWasm @ dotnet.7.0.11.s365udhifh.js:14
(anonymous) @ dotnet.7.0.11.s365udhifh.js:14
(anonymous) @ blazor.webassembly.js:1
await in (anonymous) (async)
start @ blazor.webassembly.js:1
Vt @ blazor.webassembly.js:1
await in Vt (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to fetch
at Ft.loadResourceWithoutCaching (blazor.webassembly.js:1:52219)
at Ft.loadResourceWithCaching (blazor.webassembly.js:1:51950)
loadResourceWithoutCaching @ blazor.webassembly.js:1
loadResourceWithCaching @ blazor.webassembly.js:1
Promise.then (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
start @ blazor.webassembly.js:1
Vt @ blazor.webassembly.js:1
await in Vt (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to fetch
at Ft.loadResourceWithoutCaching (blazor.webassembly.js:1:52219)
at Ft.loadResourceWithCaching (blazor.webassembly.js:1:51950)
loadResourceWithoutCaching @ blazor.webassembly.js:1
loadResourceWithCaching @ blazor.webassembly.js:1
await in loadResourceWithCaching (async)
instantiateWasm @ blazor.webassembly.js:1
mc @ dotnet.7.0.11.s365udhifh.js:5
e.instantiateWasm @ dotnet.7.0.11.s365udhifh.js:5
createWasm @ dotnet.7.0.11.s365udhifh.js:14
(anonymous) @ dotnet.7.0.11.s365udhifh.js:14
(anonymous) @ blazor.webassembly.js:1
await in (anonymous) (async)
start @ blazor.webassembly.js:1
Vt @ blazor.webassembly.js:1
await in Vt (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
Unknown error occurred while trying to verify integrity.
blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to fetch
at Ft.loadResourceWithoutCaching (blazor.webassembly.js:1:52219)
at Ft.loadResourceWithCaching (blazor.webassembly.js:1:51950)
loadResourceWithoutCaching @ blazor.webassembly.js:1
loadResourceWithCaching @ blazor.webassembly.js:1
Promise.then (async)
(anonymous) @ blazor.webassembly.js:1
start @ blazor.webassembly.js:1
Vt @ blazor.webassembly.js:1
await in Vt (async)
(anonymous) @ blazor.webassembly.js:1
(anonymous) @ blazor.webassembly.js:1
Unknown error occurred while trying to verify integrity.
blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to fetch
at Ft.loadResourceWithoutCaching (blazor.webassembly.js:1:52219)
at Ft.loadResourceWithCaching (blazor.webassembly.js:1:51950)

On firs load i have error, if i refresh the page it loads normally untill i clear the cache and try to load.
Please help if anyone know

Before publishing try to delete all "bin" and "obj" folders in your projects, it helps me. Usually this bug happens after wasm project libs updating.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[SteveSandersonMS]

Is everything here now tracked by #52824? If so we should close this in favor of that other one that has an actual plan.

@mkArtakMSFT @javiercn @MackinnonBuck

[javiercn]

This is done now as part of the fingerprinting support that we've added in preview7.

We included #57302 to track further support on standalone scenarios via a service worker.