Integrity checking issue in Blazor wasm application after update from RC2 to 5.0

[askolniak]

I have just updated references to the latest framework release and the application does not start anymore. Project is developed, build and hosted on Windows.

When started locally from Visual Studio it throws out a lot of errors such as "Failed to find a valid digest in the 'integrity' attribute for resource..." for probably all client side dlls and for dotnet.wasm.

When published and served on IIS in "self-contained" mode it throws "only" this: Failed to find a valid digest in the 'integrity' attribute for resource 'http://myserver.com/myproject/_framework/dotnet.wasm' with computed SHA-256 integrity 'sM00FtqUHIlrUdb02MY/qfdHC8Wj3ZQzQbgAHOGI/QM='. The resource has been blocked. myproject:1 Unknown error occurred while trying to verify integrity. myproject:1 Failed to find a valid digest in the 'integrity' attribute for resource 'http://myserver.com/myproject/_framework/dotnet.timezones.blat' with computed SHA-256 integrity 'eD1xx9KVSZ9Xc134LY9VKnKHGzf6M2yPGh+GxiRBQw0='. The resource has been blocked. myproject:1 Unknown error occurred while trying to verify integrity. myproject:1 Uncaught (in promise) TypeError: Failed to fetch blazor.webassembly.js:1 Streaming compilation failed. Falling back to ArrayBuffer instantiation. TypeError: Failed to fetch blazor.webassembly.js:1 TypeError: Failed to fetch d.printErr @ blazor.webassembly.js:1 (anonymous) @ blazor.webassembly.js:1 (anonymous) @ blazor.webassembly.js:1 (anonymous) @ blazor.webassembly.js:1 s @ blazor.webassembly.js:1 Promise.then (async) u @ blazor.webassembly.js:1 a @ blazor.webassembly.js:1 Promise.then (async) u @ blazor.webassembly.js:1 (anonymous) @ blazor.webassembly.js:1 r @ blazor.webassembly.js:1 d.instantiateWasm @ blazor.webassembly.js:1 createWasm @ dotnet.5.0.0.js:1 (anonymous) @ dotnet.5.0.0.js:1 blazor.webassembly.js:1 Uncaught (in promise) TypeError: Failed to fetch

When I added this line: <BlazorCacheBootResources>false</BlazorCacheBootResources> to the client side csproj and started the app locally, it threw this:

blazor.webassembly.js:1 Error: Failed to start platform. Reason: RuntimeError: memory access out of bounds 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 (anonymous) @ blazor.webassembly.js:1 Promise.catch (async) (anonymous) @ blazor.webassembly.js:1 n @ blazor.webassembly.js:1 (anonymous) @ blazor.webassembly.js:1 (anonymous) @ blazor.webassembly.js:1 dotnet.wasm:0x108d98 Uncaught (in promise) RuntimeError: memory access out of bounds at mono_wasm_load_icu_data (https://localhost:44338/_framework/dotnet.wasm:wasm-function[6919]:0x108d98) at Object.mono_wasm_load_bytes_into_heap (https://localhost:44338/_framework/dotnet.5.0.0.js:1:144722) at https://localhost:44338/_framework/blazor.webassembly.js:1:16948 at https://localhost:44338/_framework/blazor.webassembly.js:1:14045 at Object.next (https://localhost:44338/_framework/blazor.webassembly.js:1:14150) at a (https://localhost:44338/_framework/blazor.webassembly.js:1:12864)

What else should I check?

[julienGrd]

you have to clean and rebuilt your solutions and normally it will be ok, I also have these error at each new release of blazor.

For the publish version i don't know, maybe remove all your install and make a fresh install on your server see if its better ?

[rogihee]

I also had this and usually Clear and delete bin/obj dirs in source fixes it. But just to be sure I also always delete the Cache Storage in Application tab for the domain (this is where all the framework files are cached by the browser).

[askolniak]

Clean+rebuild helped to launch the application locally in my development environment, but the problem still exists after publishing to the server. Still the same: Failed to find a valid digest in the 'integrity' attribute for resource 'dotnet.wasm' Failed to find a valid digest in the 'integrity' attribute for resource 'dotnet.timezones.blat'

I always manually delete lib and bin folders when updating dependencies as without it I had binary version mismatch issues in the published folder. Browser cache cleaning and hard reset are used after every change in the client side project.

Any other tips?

[rogihee]

Do you run CloudFlare on your production site? https://github.com/dotnet/aspnetcore/issues/19828

[askolniak]

No, it is an intranet application.

[rogihee]

Did you read the docs section on it and tried everything mentioned there: https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/webassembly?view=aspnetcore-5.0#resolve-integrity-check-failures

[askolniak]

All files are served with status 200, but... I noticed that server serves the gzipped versions of these files (dotnet.wasm.gz and dotnet.timezones.blat.gz), but their contents are different than uncompressed files! When I remove the .gz files the application starts. How to eliminate this problem?

[mvujica]

Had similar problems wih integrity error on Blazor project in RC2 that was converted to final 5.0, was using VS 2019 Preview and couldn't for the life of me get it to publish corectly on local IIS 10 (Web deploy package -framework dependent-portable). Ended up creating new Blazor WASM hosted project in VS 2019 Latest Stable 16.8.0 and copied my code from first project. Deployed and running without errors. Lost a day...

[ghost]

Thanks for contacting us. We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[askolniak]

I have successfully resolved the problem. As I wrote before, I always delete the bin and obj folders when updating project dependencies, but this only applies to the "main" WebApi project, which also hosts the client-side application. I noticed that in the bin folder directly in the BlazorWebAssembly (client-side) project, next to net5.0, there is still a netstandard2.1 subfolder. So I deleted the entire bin folder of this project. Now I re-published the WebApi and gz files finally match uncompressed files. Thank you all for your help! The question remains open - though not so urgent - why were gz files copied to the publication folder from the wrong version?

[rogihee]

After many, many, many moons of working with Visual Studio and .NET I still don't understand why the basic "Clean" command does not delete the bin/obj dirs altogether. Chalk one more up on that command.

[HeroSpha]

@mvujica your solution worked for me, i have been using preview, when deployed i was getting an errors, then i published my app uisng 16.8.1 it worked

[captainsafia]

Hi folks -- the issue that you are running into is related to a bug in the build incrementalism for our compression MSBuild targets. We're hoping to get a fix out for this in the first patch of 5.0.

In the meantime, running a dotnet clean before building your app should resolve the issue.

[mvujica]

Can confirm that CLEAN before publishing in Microsoft Visual Studio Community 2019 Preview, Version 16.9.0 Preview 1.0, does not fix the integrity problem, only reverting to stable VS edition does the trick, think Publish in Preview is broken when using IIS Web deploy template.

[julienGrd]

Can confirm that CLEAN before publishing in Microsoft Visual Studio Community 2019 Preview, Version 16.9.0 Preview 1.0, does not fix the integrity problem, only reverting to stable VS edition does the trick, think Publish in Preview is broken when using IIS Web deploy template.

Im using thé 16.9 preview édition, and i dont have problem to publish with thé wizard on iis server. Maybe you have specific configuration/packagé which make this broken ?