[Broken Build]: Blazor Integrity issue

[skyslide22]

Issue Description

When deploying a blazor wasm app in dotnet 6, 7 & 8 the integrity of the dlls/wasm files are invalid, randomly. when running dotnet publish -o ../wwwroot the build succeeds but the dlls/wasm files are not updated, the old versions from the previous build(s) are taken, thus the invalid sha (error in js console any browser cache cleared)

The issue is solved when deleting every obj and bin folder in the repository. It happens on azure (MSBuild) and also locally using visual studio.

It is unpredictable if a release containing ny blazor wasm is working in the end, if would be cool if the Build can at least fail and not succeed with corrupt files. Dotnet version does not matter it seems.

The issue does not appear when the browser cache was not cleared and the files were not actually fetched, so only new users are doomed, until someone clears the cache and then also notices the app is totally broken.

Steps to Reproduce

Not sure how to reproduce this, it happens randomly I had blazor wasm projects in dotnet 6 with the syncfusion library and dotnet 6 & 8 with mudblazor, so its probably related to something different.

Expected Behavior

Ignore update previous generated dlls/wasm files on build in /bin and /obj folders

Actual Behavior

Ask us questions

Is it possible to add a feature to f.e. the csproj file that deleted the old dlls/wasm files like <DeletePreviousWasmResourcesOnBuild>true<../> ? Very annoying to push to production and then see it is actually not working, at least some parts of the app, this case i would have to check very wasm part of the entire app and see if any of them is broken, on every release i do

[AR-May]

@skyslide22 It seems like there might be some issue with incrementality in your builds. Let's try first to verify that the rebuild works without issues. Could you please instead of dotnet publish run first dotnet build /t:rebuild and then dotnet publish --no-build -o ../wwwroot? Does it lead to the same issues?

[skyslide22]

will take a look the next time we update and break stuff ^^ but it definitely happens mostly when we update the versions of any nuget package in the .csproj file

[baronfel]

@AR-May for blazor incrementality should we ask the blazor team to dig in for more details?

[AR-May]

@baronfel yes, we would need the blazor team to provide us with a binary log of the bad deployment.

[skyslide22]

I am testing it on azure right now, will give results the next days

[skyslide22]

So, i am not able to reproduce this issue, changing/adding project references/packages does not break the app, i will invenstigate further, but that will take some weeks. Will make a report when i get this issue in production again.

[skyslide22]

i get the same issues using your suggestion:

this time i did not use
dotnet publish -o ../wwwroot is not used now

but this:
dotnet build /t:rebuild 
dotnet publish --no-build -o ../wwwroot

i cleared the wwwroot folder before, but the bin & obj folders were not deleted in the project folders(/server, /client, /shared)

So i changed some code in a controller action and the result is a wasm integrity error, i have not changed anything near wasm or blazor file(s).

Failed to find a valid digest in the 'integrity' attribute for resource 
'website.net/_framework/dotnet.native.wasm' 
with computed SHA-256 integrity 'b3QtgAqvT5FoNyYgoEYsdE4zF5C1Is6lhQ8VEkROor8='. 
The resource has been blocked.

the slot(azure) where i published on was not deployed to for some weeks, maybe the issue occours when the files in bin/obj folders are too old?

[scott-the-programmer]

@skyslide22 I think the issue could be request caching, i.e. the browser is thinking that the items on-hand are the latest and greatest.

This can happen if the server is returning cache headers despite the client including no-cache in the requests.

We also included some JS prior to blazor.startup(..) to determine whether it needs to clear out any DLLs before attempting to start. This is more of a stop-gap solution as there seems to be many things that could lead to integrity issues, however, serving a dead-app is a show stopper for us.

Although don't take my word for it, keen to know if you've made any progress!

[dotnet-policy-service[bot]]

This issue is marked as stale because feedback has been requested for 30 days with no response. Please respond within 14 days or this issue will be closed due to inactivity.

[dotnet-policy-service[bot]]

This issue was closed due to inactivity. If you can still reproduce this bug, please comment with the requested information, detailed steps to reproduce the problem, or any other notes that might help in the investigation.