Blazor wasm boot.json hashes are incorrect after dotnet publish

[hhyyrylainen]

Describe the bug

I'm trying to run "dotnet publish" to get my app into a production environment. However I can't get the integrity check to pass.

I tried all the troubleshooting tips and even the integrity.ps1 script, but that doesn't (even after one temp path change) seem to work well on Linux:

$ pwsh -File integrity.ps1 https://staging.dev.revolutionarygamesstudio.com/ publish
Invoke-WebRequest: /home/hhyyrylainen/Projects/ThriveDevCenter/Client/bin/Release/net5.0/integrity.ps1:110                                                    Line |                                                                                                                                                         110 |  … viceWorkerAssetsResponse = Invoke-WebRequest $serviceWorkerAssetsUrl;                                                                                    |                               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                     | Response status code does not indicate success: 404 (Not Found).                                                                                                                                                                                                                                                     ApplicationInformation                                              

Finally I noticed when comparing the hashes in the generated blazor.boot.json with the local file I had, that the hashes are different. So it looks like the publish command doesn't calculate the hashes correctly.

This is the first hash in my blazor.boot.json:

"Microsoft.TestPlatform.PlatformAbstractions.dll": "sha256-pMsMKv33\/RjHY29C\/QzodKJ8YQ1sOg17f3Zwa6y0N\/Q=",

And it seems to be incorrect (and this is just running the dotnet publish -c Release and nothing extra, even after a fresh re-clone it doesn't work). As this is what I get when I manually calculate the hash:

$ echo "sha256-$(openssl dgst -sha256 -binary Microsoft.TestPlatform.PlatformAbstractions.dll | openssl base64 -A)"
sha256-VBEP5zNDa+gV0ghxCrL40DtQD7Ziwlw5+AJolnuguHo=

and that is also what Chrome reports as the hash that it calculated in the error message.

To Reproduce

I tried with a freshly created wasm project, but that doesn't show the issue. I though that as I don't use a static index.html (as some people referred to that regarding this issue: #19828) that deleting that from the template would maybe do something, but it doesn't. I couldn't test by dropping in my current _Host.cshtml file as it needs some changes to run without my other code.

I found one more related issue, but none of the suggestions in it worked either: #28692

It does say, that you don't want to look at my project, but here's the steps to see the problem:

git clone git@github.com:Revolutionary-Games/ThriveDevCenter.git DevTest --branch blazor
cd DevTest/
dotnet publish -c Release
echo "sha256-$(openssl dgst -sha256 -binary Client/bin/Release/net5.0/publish/wwwroot/_framework/Microsoft.TestPlatform.PlatformAbstractions.dll | openssl base64 -A)"

For reference the current latest commit is: 9e4aef415e3088fb526092d71e08e18a9c37995a

And then check that Client/bin/Release/net5.0/publish/wwwroot/_framework/blazor.boot.json has a different hash for that dll file.

Someone suggested to make a script that calculates the right hashes and updates blazor.boot.json: https://swimburger.net/blog/dotnet/fix-blazor-webassembly-pwa-integrity-checks which I'll probably do if no one can help me with this, though it doesn't seem very optimal.

Exceptions (if any)

Failed to find a valid digest in the 'integrity' attribute for resource 'https://staging.dev.revolutionarygamesstudio.com/_framework/Microsoft.TestPlatform.PlatformAbstractions.dll' with computed SHA-256 integrity 'VBEP5zNDa+gV0ghxCrL40DtQD7Ziwlw5+AJolnuguHo='. The resource has been blocked.
staging.dev.revolutionarygamesstudio.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)

Further technical details

• ASP.NET Core version: 5.0.4
• Include the output of dotnet --info

.NET SDK (reflecting any global.json):
 Version:   5.0.103
 Commit:    72dec52dbd

Runtime Environment:
 OS Name:     fedora
 OS Version:  32
 OS Platform: Linux
 RID:         fedora.32-x64
 Base Path:   /usr/lib64/dotnet/sdk/5.0.103/

Host (useful for support):
  Version: 5.0.3
  Commit:  c636bbdc8a

.NET SDKs installed:
  3.1.112 [/usr/lib64/dotnet/sdk]
  5.0.103 [/usr/lib64/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.12 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.3 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.12 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.3 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

[javiercn]

@hhyyrylainen thanks for contacting us.

What does the integrity.ps1 script say?

Are you using git for deployment or something like that?

[hhyyrylainen]

I'm not using git for deployment. I use rsync to sync my local files to a server, but even when locally checking the hashes, my local files have different hashes than what got computed into blazor.boot.json. And I checked the hashes of a dll file I downloaded back from the server with what my local files, and those were the same. So I don't think my files are changing when putting them on the server or downloading them from there.

Looks like markdown ate the line breaks in the ps script output. Here it is as an image:

And this is what I got before I adjusted the temp file path:

Both of these took like more than 5 minutes to run (I left them in the background as the script didn't seem to progress so I can't exactly say when it finished). Which gives me the impression that the script doesn't work super well on Linux.

[javiercn]

@hhyyrylainen a few more questions:

• Do all the files contain have different hashes?
• Is there a specific set of files that has different hashes?
  • Can you give us a list?

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.

[hhyyrylainen]

I actually just finished making that script (in ruby) that fixes incorrect hashes (if anyone wants it, it's here: https://github.com/Revolutionary-Games/ThriveDevCenter/blob/fc1534d8c67b3cf2bb228dee290c3935f7cf393c/fix_boot_json_hashes.rb)
And I immediately noticed one thing: only one of the files has an incorrect hash.
Output from that script:

Checking boot file: Client/bin/Release/net5.0/publish/wwwroot/_framework/blazor.boot.json
Invalid hash detected for entry: Microsoft.TestPlatform.PlatformAbstractions.dll

So it seems like only Microsoft.TestPlatform.PlatformAbstractions.dll has an incorrect hash.
After adding that script as a step in my deploy script and deploying it to my server, the site now loads correctly both in Firefox and Chrome with cacheBootResources on.

[javiercn]

@hhyyrylainen that's strange, I don't think you should have that reference in a blazor webassembly application

[hhyyrylainen]

Looking into if I can figure out how to cut down on the Client assembly dependencies, was going to be my next step. I see that also xunit (which I've used in the Shared project) gets included in the Client.
I think I need to look into how I can include tests in the Shared project without the Client build pulling in those dependencies as well.

[hhyyrylainen]

Okay, so I didn't find any guide on how to do this. So I tried a few things and then ultimately ended up splitting the tests into a separate project called Shared.Tests. Now the test files no longer show up in blazor.boot.json but for some reason they still get copied to the wwwroot folder. Luckily, though the browser doesn't load those files at least. So that isn't a huge problem.

So now, my hash checking script no longer finds any errors as the boot.json no longer references that one problematic file.

[javiercn]

@hhyyrylainen that's the common practice in .NET in general, tests go into a separate project, otherwise you bring in all the test dependencies to your product, which I don't think you want to do.

[hhyyrylainen]

@javiercn thanks for the tip. This is the first time I'm working on a C# project of this kind, so I just went with the first guide I found, and that said to just put tests in a separate folder.

I suppose this issue can be closed, then, if it isn't useful for the future to figure out why dotnet publish can't get the hash correct on Microsoft.TestPlatform.PlatformAbstractions.dll