[dotnet-sdk-10.0.100-preview.1.25103.13] Apps retarget failed with error "The following scoped CSS bundles do not have matching endpoints"

[Junjun-zhao]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Description:
When retargeting apps with NET10.0, it will throw: “The following scoped CSS bundles do not have matching endpoints”.

Application Name: Hawaso, Blazor-Blogs, BootstrapBlazor, OpenMU, WorldExplorer
OS： Windows 10 21H2
CPU: X64
.NET Build Number: dotnet-sdk-10.0.100-preview.1.25103.13
App & Source Location checking at: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2379240

Github Link:
https://github.com/VisualAcademy/Hawaso
https://github.com/ADefWebserver/Blazor-Blogs
https://github.com/MUnique/OpenMU
https://github.com/dotnetcore/BootstrapBlazor
https://github.com/VladislavAntonyuk/WorldExplorer

Expected Behavior

Build successfully.

Steps To Reproduce

Minimal Repro steps (Demo attached:BlazorTest.zip):

1. Create a default 9.0 blazor web project.
2. Right click on Solution>Properties, Retarget framework selection 10.0.
3. Reference the NuGet package 'Blazored. Toast' (NuGet Gallery | Blazored.Toast 4.2.1).
4. Build Solution.

Exceptions (if any)

Build Failed with below errors:

C:\Program Files\dotnet\sdk\10.0.100-preview.1.25103.13\Sdks\Microsoft.NET.Sdk.StaticWebAssets\targets\Microsoft.NET.Sdk.StaticWebAssets.ScopedCss.targets(415,3): error: The following scoped css bundles do not have matching endpoints: Blazored.Toast.bundle.scp.css

.NET Version

10.0.100-preview.1.25103.13

Anything else?

Dotnet info:

.NET SDK:
 Version:           10.0.100-preview.1.25103.13
 Commit:            9035d02b05
 Workload version:  10.0.100-manifests.bf5105ba
 MSBuild version:   17.14.0-preview-25073-02+291a81087

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.100-preview.1.25103.13\

Host:
  Version:      10.0.0-preview.1.25080.5
  Architecture: x64
  Commit:       b98cabca12

.NET SDKs installed:
 10.0.100-preview.1.25103.13 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
 Microsoft.AspNetCore.App 10.0.0-preview.1.25103.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
 Microsoft.NETCore.App 10.0.0-preview.1.25080.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 10.0.0-preview.1.25080.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

@dotnet-actwx-bot @dotnet/compat

[Junjun-zhao]

@mkArtakMSFT @lewing This issue was found during our source compat testing, could you please have a look at this issue and confirm if this is a blocker for .NET 10 Preview1? Thank you.

[CancanTang]

@mkArtakMSFT @lewing @danroth27, I saw that it was added to the 10.0-preview2 milestone. However, I didn't see any related PR links tracking the fix here. Could you please confirm if this is a blocker for .NET 10 Preview2 ?

[adrianvince7]

Reproduced this error on a net9 blazor project on net10 preview 2

0>Microsoft.NET.Sdk.StaticWebAssets.JSModules.targets(226,3): Error : The following scoped css bundles do not have matching endpoints: MudBlazor.Extensions.lib.module.js

[Junjun-zhao]

Hi @javiercn , Thanks for looking into this issue. Is there any update or schedule for this issue?

[richardhauer]

It seems like some of my dependent packages include a Microsoft.AspNetCore.StaticWebAssets.props that have JS and CSS <StaticWebAsset /> references that do not include the mandatory endpoint property fingerprint.

In the case of MudBlazor.Extensions v8.3.1, it seems like the package was built against net8.0 before the new MapStaticAssets features were introduced, and the lack of backward compatibility in the build system is causing this issue. That is, the 10.0-preview2 build targets make assumptions about the <EndpointProperties /> properties that will be configured against assets included by referencing in dependent packages, specifically the fingerprint which is missing in this case... it hadn't been invented yet. Not sure how you'd resolve this, but it's not great to say that "to use net10.0 all your dependent packages will have to have been built against at least net9.0", since there are many useful packages for which this is not true. Case in point.

Ok, so, having said all of that, I was able to get the build going by adding two properties into my various .csproj files:

<StaticWebAssetStandaloneHosting>true</StaticWebAssetStandaloneHosting>
<DisableBuildCompression>true</DisableBuildCompression>

These had to be added to all projects that used the Microsoft.NET.Sdk.Razor sdk and contained (or indirectly reference) the offending Mudblazor.Extensions package.

It's not entirely clear from my reading whether <StaticWebAssetStandaloneHosting /> will have additional side-effects aside from simply ignoring the fingerprint features.

See C:\Program Files\dotnet\sdk\10.0.100-preview.2.25164.34\Sdks\Microsoft.NET.Sdk.StaticWebAssets\targets\Microsoft.NET.Sdk.StaticWebAssets.JSModules.targets:

<Target Name="GenerateJSModuleManifestPublishStaticWebAssets" DependsOnTargets="$(GenerateJSModuleManifestPublishStaticWebAssetsDependsOn)">
  <!-- Incrementalism is built into the task itself. -->
  <ItemGroup>
    <!-- If we are in standalone hosting, we want to resolve endpoints that match the file name, that's what standalone does -->
    <_JsModulePublishManifestFilters Include="Standalone" Condition="$(StaticWebAssetStandaloneHosting) == 'true'" />
    <!-- If we are not in standalone hosting, we want to resolve endpoints with a fingerprint where possible -->
    <_JsModulePublishManifestFilters Include="Property" Condition="$(StaticWebAssetStandaloneHosting) != 'true'">
      <Name>fingerprint</Name>
    </_JsModulePublishManifestFilters>
    <_JsModulePublishManifestFiltersNoFingerprint Include="Property" Condition="$(StaticWebAssetStandaloneHosting) != 'true'">
      <Name>fingerprint</Name>
      <Mode>Exclude</Mode>
    </_JsModulePublishManifestFiltersNoFingerprint>
  </ItemGroup>
  ...
</Target>

So, by setting the value to true we basically tell the build to not look for the (missing) fingerprint property on the included module's StaticWebAsset, and thus avoid the error.

The compression issue arises because there is another build task that is presumably also looking for the fingerprint but does not apply the StaticWebAssetStandaloneHosting condition first. This time we're looking at C:\Program Files\dotnet\sdk\10.0.100-preview.2.25164.34\Sdks\Microsoft.NET.Sdk.StaticWebAssets\targets\Microsoft.NET.Sdk.StaticWebAssets.Compression.targets, in the target ResolveBuildCompressedStaticWebAssets and the task ApplyCompressionNegotiation which crashes out with the following stack trace:

C:\Program Files\dotnet\sdk\10.0.100-preview.2.25164.34\Sdks\Microsoft.NET.Sdk.StaticWebAssets\targets\Microsoft.NET.Sdk.StaticWebAssets.Compression.targets(243,5): warning : Endpoints not found for related asset: C:\Users\***\.nuget\packages\mudblazor.extensions\8.3.1\staticwebassets\css\mudExAppLoader.css

The "ApplyCompressionNegotiation" task failed unexpectedly.
System.InvalidOperationException: Endpoints not found for related asset: C:\Users\***\.nuget\packages\mudblazor.extensions\8.3.1\staticwebassets\css\mudExAppLoader.css
    at Microsoft.AspNetCore.StaticWebAssets.Tasks.ApplyCompressionNegotiation.Execute()
    at Microsoft.Build.BackEnd.TaskExecutionHost.Execute()
    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

I lose the thread in the task DefineStaticWebAssetEndpoints that has an output of Endpoints. Presumably the endpoint for some assets are being omitted on the basis that they are missing fingerprints? Or perhaps for some other reason.

For my purposes, compression is not important as this is a desktop app with files on the local disk, hence compression is actually a performance penalty, so it's sufficient to simply disable it entirely. Likely the size of the package will be increased as a result. Again, not a big issue for me at present.

[javiercn]

This was addressed on the 10.0 SDK dotnet/sdk#47734 and the fix is available on 10.0.100-preview.4.25221.10 and above