ApplyCompressionNegotiation build task fails when RCL references a Nuget RCL with StaticWebAssetBasePath set to /

[LostBeard]

Description

Issue

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

Reproduction Steps

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, add a PackageReference to the Nuget package from step 2 (a ProjectReference does not trigger the bug)
5. In the Blazor WASM app add a ProjectReference to the RCL project in the same solution
6. Run dotnet publish --nologo --configuration Release --output bin\Publish in the Blazor WASM app folder to see the error.

You get an exception similar to:

D:\users\tj\Projects\Issue4\WebWorkers.Issue4\WebWorkers.Issue4>dotnet publish --nologo --configuration Release --output "D:\users\tj\Projects\Issue4\WebWorkers.Issue4\WebWorkers.Issue4\bin\Publish\"
Restore complete (0.5s)
  RazorClassLibrary1 net9.0 succeeded (3.3s) → D:\users\tj\Projects\Issue4\WebWorkers.Issue4\RazorClassLibrary1\bin\Release\net9.0\RazorClassLibrary1.dll
  RazorClassLibrary1 net9.0 succeeded (0.1s) → D:\users\tj\Projects\Issue4\WebWorkers.Issue4\RazorClassLibrary1\bin\Release\net9.0\RazorClassLibrary1.dll
  WebWorkers.Issue4 failed with 1 error(s) and 1 warning(s) (0.6s)
    C:\Program Files\dotnet\sdk\9.0.100\Sdks\Microsoft.NET.Sdk.StaticWebAssets\targets\Microsoft.NET.Sdk.StaticWebAssets.Compression.targets(323,5): warning : Endpoints not found for compressed asset: example.JsInterop.faux.js.gz D:\users\tj\Projects\Issue4\WebWorkers.Issue4\WebWorkers.Issue4\obj\Release\net9.0\compressed\87ntuufp02-gq62o8712c.gz
    C:\Program Files\dotnet\sdk\9.0.100\Sdks\Microsoft.NET.Sdk.StaticWebAssets\targets\Microsoft.NET.Sdk.StaticWebAssets.Compression.targets(323,5): error MSB4018:
      The "ApplyCompressionNegotiation" task failed unexpectedly.
      System.InvalidOperationException: Endpoints not found for compressed asset: D:\users\tj\Projects\Issue4\WebWorkers
      .Issue4\WebWorkers.Issue4\obj\Release\net9.0\compressed\87ntuufp02-gq62o8712c.gz
         at Microsoft.AspNetCore.StaticWebAssets.Tasks.ApplyCompressionNegotiation.Execute()
         at Microsoft.Build.BackEnd.TaskExecutionHost.Execute()
         at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(TaskExecutionHost taskExecutionHost, TaskLogging
      Context taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)
  WebWorkers.Issue4 failed (9.7s) → bin\Release\net9.0\wwwroot

Build failed with 1 error(s) and 1 warning(s) in 15.4s

7. Workaround: Disable compression (<CompressionEnabled>false</CompressionEnabled>) in the 2nd solution's Razor Class Library's .csproj and the publish will succeed and all static web assets will compress normally.

This issue started as a report about an issue (#4) with SpawnDev.BlazorJS.WebWorkers.

Repo that has projects to demonstrate the issue: WebWorkers.Issue4

Expected behavior

I expected StaticWebAssetBasePath to work in .Net 9 as it did in .Net 8. This issue did not exist in .Net 8.

Actual behavior

publish builds fail with the error:

The "ApplyCompressionNegotiation" task failed unexpectedly.
      System.InvalidOperationException: Endpoints not found for compressed asset: 

Regression?

Unknown

Known Workarounds

Disable compression with <CompressionEnabled>false</CompressionEnabled> in Razor Class Libraries .csproj.

Configuration

dotnet --info

.NET SDK:
Version: 9.0.100
Commit: 59db016f11
Workload version: 9.0.100-manifests.4a280210
MSBuild version: 17.12.7+5b8665660

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19045
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.100\

.NET workloads installed:
[android]
Installation Source: SDK 9.0.100, VS 17.13.35507.96
Manifest Version: 35.0.7/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.android\35.0.7\WorkloadManifest.json
Install Type: Msi

[aspire]
Installation Source: SDK 9.0.100, VS 17.11.35327.3
Manifest Version: 8.2.2/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
Install Type: Msi

[ios]
Installation Source: SDK 9.0.100, VS 17.13.35507.96
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.ios\18.1.9163\WorkloadManifest.json
Install Type: Msi

[maccatalyst]
Installation Source: SDK 9.0.100, VS 17.13.35507.96
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maccatalyst\18.1.9163\WorkloadManifest.json
Install Type: Msi

[maui-windows]
Installation Source: SDK 9.0.100, VS 17.13.35507.96
Manifest Version: 9.0.0/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.0\WorkloadManifest.json
Install Type: Msi

[wasm-tools]
Installation Source: SDK 9.0.100
Manifest Version: 9.0.0/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.current\9.0.0\WorkloadManifest.json
Install Type: Msi

[wasm-tools-net8]
Installation Source: SDK 9.0.100
Manifest Version: 9.0.0/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.net8\9.0.0\WorkloadManifest.json
Install Type: Msi

Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.0
Architecture: x64
Commit: 9d5a6a9aa4

.NET SDKs installed:
6.0.102 [C:\Program Files\dotnet\sdk]
6.0.202 [C:\Program Files\dotnet\sdk]
6.0.300 [C:\Program Files\dotnet\sdk]
6.0.302 [C:\Program Files\dotnet\sdk]
7.0.100-rc.1.22431.12 [C:\Program Files\dotnet\sdk]
7.0.102 [C:\Program Files\dotnet\sdk]
7.0.200 [C:\Program Files\dotnet\sdk]
8.0.101 [C:\Program Files\dotnet\sdk]
8.0.204 [C:\Program Files\dotnet\sdk]
8.0.303 [C:\Program Files\dotnet\sdk]
8.0.401 [C:\Program Files\dotnet\sdk]
8.0.403 [C:\Program Files\dotnet\sdk]
9.0.100-rc.2.24474.11 [C:\Program Files\dotnet\sdk]
9.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.35 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.0-rc.1.22427.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0-rc.2.24474.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.35 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.0-rc.1.22426.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0-rc.2.24473.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.35 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.0-rc.1.22427.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.0-rc.2.24474.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

Learn more:
https://aka.ms/dotnet/info

Download .NET:
https://aka.ms/dotnet/download

Other information

See repo: WebWorkers.Issue4

[LostBeard]

One workaround is to disable compression and the publish builds will succeed.

In the Blazor WASM project's .csproj

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

Another is to use .Net 8 instead of .Net 9 as the issue does not occur in .Net 8.

[LostBeard]

Better workaround...

Razor Class Libraries that use Nuget packages affected by this bug can set <CompressionEnabled>false</CompressionEnabled> and then the Blazor WASM app can still use compression normally. Maybe the compression stage is being ran twice? Once for the RCL and again for Blazor app?

[nobba]

The workaround with setting compression to false in the wrapper lib does not work for us, when consuming Webworkers in the wrapper class library and then this wrapper in Blazor application. Setting in the application works but this is obviously not a good solution. Strange that you got it working.

[LostBeard]

@nobba

Strange that you got it working.

Or... maybe strange that you did not? lol

I'm assuming you tried the workaround in your existing problematic setup, and not the demo repo I linked.

(Trying to spot differences between your setup and the demo setup...)
As we have discussed this issue elsewhere, I assume your RCL is referencing a Nuget RCL that uses <StaticWebAssetBasePath>/</StaticWebAssetBasePath>.
Is your RCL being used in a Blazor app as a Nuget package via PackageReference or as a project via a ProjectReference?

The workaround is tested and working in the linked basic minimal setup. An in depth solution, like yours, may have other parts contributing to the issue. If you can share your solution or create a minimal setup to reproduce your particular issue, you may get some help before .Net 10.

javiercn
added this to the .NET 10 Planning milestone yesterday

Ouch.

Unfortunate workaround

It seems, for now, the best publishers of .Net 9 RCL Nuget packages can do is warn package consumers that:
publish builds for .Net 9 Blazor apps may fail unless compression is disabled or the app switches to .Net 8.

As compression is enabled by default in Blazor apps, even if the compressed assets are not used, this issue will be more widespread than it needs to be.

[LostBeard]

The workaround with setting compression to false in the wrapper lib does not work for us, when consuming WebWorkers in the wrapper class library and then this wrapper in Blazor application.

That is literally how the demo app is setup. :-) RazorClassLibrary1 references the WebWorkers Nuget package (WebWorkers uses <StaticWebAssetBasePath>/</StaticWebAssetBasePath>) and the .Net 9 Blazor app WebWorkers.Issue4 references RazrClassLibrary1.

I am really curious as to why it is not working in your setup. Would love to help figure it out.

How to use issue demo repo WebWorkers.Issue4:
To see the issue:

• Clone repo
• Run _publish.bat in WebWorkers.Issue4 folder to do a Release publish build
• The "ApplyCompressionNegotiation" task failed unexpectedly ...

Test workaround:

• Uncomment <CompressionEnabled>false</CompressionEnabled> in RazorClassLibrary1.csproj
• Run _publish.bat in WebWorkers.Issue4 folder to do a Release publish build
• Build succeeded

[LostBeard]

@nobba

Another workaround that may work for you is to target .Net 8 instead of .Net 9 in your RCL. The app can still target .Net 9 and a publish build with compression still works.

Another workaround

Do not target .Net 9 in your Razor Class Library. If net9.0 is not included in the target frameworks in the RCL, the issue does not occur.

[nobba]

@LostBeard,

Ok, so the difference seems to be that we have a Blazor WASM Hosted solution (earlier called "Hosted" template and now called "Auto" when creating the solution), where the Client WASM is hosted/delivered by the Server. Note that for this configuration the Server project is published.

So the dependency chain is
Webworker -> Wrapper -> Client -> Server and then Publish. This will cause the error dispite setting CompressionEnabled false.

Grateful for any idea of how to work around, I cant seem to configure the projects to get around the issue.

[javiercn]

@LostBeard thanks for the details.

The issue seems to be https://github.com/dotnet/sdk/blob/111a3978de0863eecf91b46df1e0f1b4c66c51b4/src/StaticWebAssetsSdk/Targets/Microsoft.NET.Sdk.StaticWebAssets.References.targets#L235

That should be the output from https://github.com/dotnet/sdk/blob/main/src/StaticWebAssetsSdk/Targets/Microsoft.NET.Sdk.StaticWebAssets.References.targets#L231C59-L231C97

[LostBeard]

@javiercn

So very happy you were able to locate the issue! Very excited to see this fixed.