Use Framework SourceType for WASM pass-through assets in multi-client solutions

[lewing]

Summary

When multiple Blazor WebAssembly client projects reference the same runtime pack, pass-through files (JS, maps, ICU data, native wasm) share a NuGet cache path. This causes duplicate Identity keys in the static web assets pipeline, crashing DiscoverPrecompressedAssets with an ArgumentException on ToDictionary.

Root Cause

PR #124125 correctly changed WASM ContentRoot from project-specific OutputPath copies to per-item %(RootDir)%(Directory) (pointing to the real file in the NuGet cache). This fixed staleness on incremental builds. However, when two WASM client projects reference the same runtime pack, shared files like dotnet.js.map now resolve to identical NuGet cache paths, producing duplicate Identity values.

Fix

Instead of copying pass-throughs to the intermediate output path (which risks re-introducing the staleness bug #124125 fixed), materialize them to a per-project obj/fx/{PackageId}/ directory using the Framework SourceType convention from the SWA SDK (dotnet/sdk#53135).

• Pass-through files (JS, maps, ICU, native wasm, and DLLs when WebCil is disabled): copied to obj/fx/{PackageId}/, registered with SourceType="Framework"
• WebCil-converted files: remain in obj/webcil/, registered with SourceType="Computed" (already per-project)
• Satellite assemblies: placed in culture subdirectories in both cases
• Both groups get per-item ContentRoot for correct Identity resolution

Architecture

This follows the SWA Framework materialization pattern: framework assets are "adopted" by each consuming project, giving them unique per-project Identity values while properly modeling the ownership relationship. AssetMode=CurrentProject prevents assets from leaking to references.

Dependencies

Requires SDK support for SourceType="Framework" from dotnet/sdk#53135.

Testing

Validated with:

• Multi-client build (2 WASM clients): ✅ 221 framework assets materialized per project
• Multi-client publish: ✅ Both clients produce 141 fingerprinted files
• Incremental rebuild: ✅
• WebCil disabled (WasmEnableWebcil=false): ✅ All files as Framework pass-throughs
• aspnetcore Components.TestServer (3 WASM clients, WasmMinimal + WasmRemoteAuthentication + BasicTestApp): ✅ Build succeeded, 0 errors

Related

• Fixes crash introduced by Fix WASM boot config ContentRoot to use IntermediateOutputPath #124125
• Depends on Add Framework SourceType for static web assets sdk#53135 (Framework SourceType support)
• Supersedes approach in Handle duplicate static web asset identities gracefully sdk#53305 / Handle duplicate Identity in SWA dictionary construction sdk#53328 (skip-duplicate)

[Copilot]

Pull request overview

This PR addresses a build-time crash in multi-Blazor-WASM-client solutions caused by duplicate StaticWebAsset Identity values when multiple projects reference the same runtime pack files from the NuGet cache. It does so by copying “pass-through” runtime assets into a per-project intermediate directory so each project’s asset Identity resolves to a unique on-disk path.

Changes:

• Identify WebCil candidates that aren’t already produced under the project’s $(IntermediateOutputPath)webcil/ folder.
• Copy those pass-through files into $(_WasmBuildWebcilPath) to ensure per-project uniqueness.
• Re-add the copied items as WebCil candidates and track the copied outputs in FileWrites.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[lewing]

After further analysis and feedback, the SDK-only approach is the better fix. Created dotnet/sdk#53328 which handles duplicate Identity in ToAssetDictionary, DiscoverPrecompressedAssets, GenerateStaticWebAssetsManifest, and GenerateStaticWebAssetEndpointsManifest.

The copy-based approach in this PR re-introduces the staleness problem that #124125 was fixing — if the runtime pack changes on incremental build and ConvertDllsToWebcil doesn't re-run, copies in obj/ go stale. The SDK-only fix avoids this entirely.

Planning to close this PR in favor of the SDK fix.

Stale

[javiercn]

Copying locally is the right approach for the time being. We shouldn't include multiple conflicting definitions of the same asset in the pipeline.

[lewing]

Updated to use Javier's preferred approach: Framework SourceType (from dotnet/sdk#53135) instead of the copy-to-intermediate pattern.

What changed

Pass-through files are now materialized to obj/fx/{PackageId}/ and registered with SourceType="Framework" via a second DefineStaticWebAssets call, while webcil-converted files remain SourceType="Computed". This follows the SWA Framework convention where framework assets are adopted by each consuming project with unique per-project Identity values.

Why this is better than the previous approach

1. No staleness risk — if the runtime pack changes, the framework materialization path stays consistent and SkipUnchangedFiles handles incrementality correctly
2. Architecturally correct — uses the same Framework SourceType pattern that the SWA SDK uses for other framework assets
3. No duplicate Identity — each project materializes to its own obj/fx/{PackageId}/ directory

Validation

• Multi-client build/publish with 2 WASM clients ✅
• aspnetcore Components.TestServer with 3 WASM clients ✅
• WebCil disabled mode ✅
• Incremental rebuild ✅

Dependency

This PR requires dotnet/sdk#53135 to be merged first (adds Framework SourceType support to the SDK).

[lewing]

Closing in favor of #125329 which is a clean PR for the Framework SourceType approach. This PR's branch was force-pushed over and no longer has the original copy-based approach history.