Error when publishing Blazor Hosted WASM .NET 9

[nobba]

Hi,
and thank you for your effort and the great library!

We get an error during publish of our Blazor Hosted WASM application after moving to .NET 9.
Everything builds and we can debug the app in VS 2022, but when publishing we get error saying:

"
Endpoints not found for compressed asset: spawndev.blazorjs.webworkers.empty.js.gz
The "ApplyCompressionNegotiation" task failed unexpectedly
at Microsoft.AspNetCore.StaticWebAssets.Tasks.ApplyCompressionNegotiation.Execute()
"
Any idea what might be off?
As a possibly related note, we had to set the StaticWebAssetBasePath in our wrapper to your package, otherwise
ImportShimBlazorWASM complained about a missing base path.

Difficult to provide an example since it is during publish, but will try to provide more info based on what you might need.

[LostBeard]

Thank you for creating an issue.

I have reproduced the issue. The issue is related to .Net 9's static web assets compression build task and SpawnDev.BlazorJS.WebWorkers being used from a Razor Class Library. I am looking into what, exactly, is triggering the issue so I can fix it. In the meantime, there are 2 workarounds that I have found:

Disable compression

In your Blazor WASM app's .csproj:

<PropertyGroup>
    <CompressionEnabled>false</CompressionEnabled>
</PropertyGroup>

Use .Net 8

In your Blazor WASM app's .csproj:

<PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
</PropertyGroup>

Issue test repo

I created a repo for a very basic project that reproduces the issue for testing: WebWorkers.Issue4

[nobba]

Thank you for your quick response!

Yes, I nibbled on that workaround but only put it in our wrapper library. As you noted above, the directive needs to go into all the depending projects, but yes it does work.

Would be glad to test any fix in the future.

[LostBeard]

Unfortunately, it looks like the issue is actually in the .Net 9 SDK.

Bug:
The .Net 9 Blazor WASM compression build task, ApplyCompressionNegotiation, fails due to an unknown issue handling Razor Class Library Nuget packages that use <StaticWebAssetBasePath>/</StaticWebAssetBasePath> when referenced by another Razor Class Library

To reproduce:

1. Create a solution with a .Net 9 Razor Class Library (RCL) and set <StaticWebAssetBasePath>/</StaticWebAssetBasePath> in its .csproj.
2. Publish the RCL as a Nuget package (publishing locally is fine)
3. Create a new solution with an .Net 9 Razor Class Library and a .Net 9 Blazor WASM
4. In the RCL, reference the Nuget package from step 2
5. In the Blazor WASM app reference the RCL project in the same solution
6. Publish the Blazor WASM

I found out I can workaround the publish issue by changing <StaticWebAssetBasePath>/</StaticWebAssetBasePath> to <StaticWebAssetBasePath>/./</StaticWebAssetBasePath> in WebWorkers. A publish build will work then... however it breaks debug builds/debugging. I documented the issue on the test repo: WebWorkers.Issue4

[LostBeard]

I reported the issue here: ApplyCompressionNegotiation build task fails when RCL references a Nuget RCL with StaticWebAssetBasePath set to /

[LostBeard]

My tests show that you can set <CompressionEnabled>false</CompressionEnabled> in your Razor Class Library that references SpawnDev.BlazorJS.WebWorkers as an effective workaround to the issue. You do not have to set the flag in the Blazor app that references your RCL and the Blazor app can still use compression normally.

[LostBeard]

As this is a bug in .Net 9 and I do not have a way to prevent it from inside WebWorkers I am closing this. I added notes about this issue on the WebWorkers README.md in the Supported .Net Version section.