dotnet.timezones.blat & dotnet.timezones.blat.gz do not have the same contents on Publish (stale file in publish folder)

[mikelyncheski]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The symptom is receiving the following message when trying to load the published website on our test server:

Failed to find a valid digest in the 'integrity' attribute for resource 'http://SERVER_NAME:5555/_framework/dotnet.timezones.blat' with computed SHA-256 integrity '44J/Hf/X8VbgiBAazDB8c0FaVrAFYOb4BbGyQwuzNyk='. The resource has been blocked.

Based on feedback on a previous issue (#27752), I deleted the dotnet.timezones.blat.gz and the site started functioning again.

The dotnet.timezones.blat.gz file looks like this:

talb�4 [["zone.tab",17593],["Australia/Eucla",314],["Australia/ACT",904],["Australia/Lindeman",325],["Australia/Brisbane",289],["Australia/Queensland",289],["Australia/Broken_Hill ....

The dotnet.timezones.blat looks like this:

talb�4 [["zone.tab",17593],["Atlantic/Azores",1453],["Atlantic/Jan_Mayen",676],["Atlantic/Faroe",441],["Atlantic/Faeroe",441],["Atlantic/South_Geo

My guess is that the checksum is built off the uncompressed file version, but IIS serves up the compressed version of the file if available.

Other points:

• It is not just my machine. Another developer on the project is having the same issue with the publish.
• We are using AspNetCore 6.0.7.
• Build/Clean did not help.
• Whacking the publish folder did not help.

For now, we will delete the dotnet.timezones.blat.gz as part of our publishing.

Expected Behavior

The website should load properly without checksum error.

Steps To Reproduce

"$MSBUILD" $SOLUTION/Arup.Server/Xxx.Server.csproj '/property:Configuration='$TARGET '/property:DeployOnBuild=true' '/property:PublishProfile=InstallToZip'

Exceptions (if any)

No response

.NET Version

6.0.7

Anything else?

No response

[mkArtakMSFT]

Thanks for contacting us.
Did you try to remove the obj folder of your project before publishing?
We'll look into improving this area in the future.

[praschl]

Same problem here.

The dotnet.timezones.blat is requested, and the hash for it is rejected. We also compared the hashes, and it seems the hash for the compressed files belongs to the uncompressed file.

As @mikelyncheski pointed out, deleting the compressed files after publish fixes the issue.

This is the only file that has this issue.

[ghostinside]

experiencing the same issue publishing the website to azure static app, using on-premises iis hosting does not meet this issue (basically when hosting on IIS, the framework does not request this file)

[ghostinside]

juts this step helped

del $(build.artifactstagingdirectory)\wwwroot_framework\dotnet.timezones.blat.gz
del $(build.artifactstagingdirectory)\wwwroot_framework\dotnet.timezones.blat.br

[mphilipp622]

I'm facing the same issue on a published Blazor WASM hosted project that's running on an Amazon Linux 2022 EC2 instance using Apache. I removed the .gz and .br files from the published directory, but no luck. I'm not having the issue on Firefox. I'm assuming this is because Firefox doesn't support PWA's anymore and maybe ignores the service worker?

[paulguz-datapa]

Same here. Had to remove the compressed files.

[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.

[mkArtakMSFT]

@lewing FYI

[dotnet-policy-service]

Tagging subscribers to this area: @directhex, @matouskozak
See info in area-owners.md if you want to be subscribed.

[steveisok]

@lewing I'll put this on 9.0 for now. Feel free to move it around.

[pavelsavara]

I think this is yet another manifestation of broken incremental publish #98690

[lewing]

closing as a duplicate of #98690