Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

Blazor WASM Hosted Scenario Analysis

Testing revealed that the existing MultiClientHostedBuild test in src/mono/wasm/Wasm.Build.Tests/Blazor/MiscTests.cs explicitly asserts that framework files are physically present in bin/<config>/<tfm>/wwwroot/_framework/:

// Lines 169-179
string client1Framework = Path.Combine(client1Dir, "bin", config.ToString(),
    DefaultTargetFrameworkForBlazor, "wwwroot", "_framework");

Assert.True(Directory.Exists(client1Framework), ...);
Assert.Contains(client1Files, f => Path.GetFileName(f).StartsWith("dotnet.") && f.EndsWith(".js"));

This test creates two Blazor WASM client projects hosted by a single server and verifies that each client gets its own physical framework files — validating the Framework SourceType materialization path that gives each client unique per-project Identity for shared runtime pack files (dotnet.native.js, ICU data, etc.).

Impact Summary

Next Steps

Options to consider:

1. Update the test assertions to check obj/ locations (via manifest) instead of bin/wwwroot/_framework/
2. Make the behavior opt-in via a property (e.g. <WasmCopyFrameworkFilesToOutput>false</WasmCopyFrameworkFilesToOutput>)
3. Only suppress copy for non-hosted scenarios where no other project references the WASM client

CI Failure Analysis

All 4 failing jobs are caused by this PR. None are infrastructure or known issues.

Summary

All 4 jobs are WasmBuildTests (Mono + CoreCLR × Linux + Windows). Every failure has the same root cause — tests expect framework files in bin/<config>/net11.0/wwwroot/_framework/ but they're no longer copied there due to the CopyToOutputDirectory=Never change.

Failing Tests (13 unique across 4 jobs)

All fail with: Could not find <file> in bundle directory: .../bin/.../wwwroot/_framework

Root Cause in Test Code

The common assertion point is ProjectProviderBase.AssertDotNetFilesSet() which scans bin/.../wwwroot/_framework/ for expected framework files. With CopyToOutputDirectory=Never, these files remain in obj/ and are served via the static web assets manifest — but the test assertions still expect them physically in bin/.

Known Issues

Build Analysis flagged 3 known issues (#109653, #125244, #117164) but none match these failures. These are genuinely new failures introduced by the PR.

Next Steps

To land this change, the test assertions in ProjectProviderBase.cs (and possibly MiscTests.cs for MultiClientHostedBuild) need to be updated to reflect the new behavior where framework files are no longer copied to bin/wwwroot/_framework/ during build.

🤖 Copilot Code Review — PR #126407

Holistic Assessment

Motivation: This PR optimizes WASM development builds by eliminating ~178 unnecessary file copies to bin/wwwroot/_framework/. During development, dotnet run uses the static web assets middleware to serve framework files directly from their obj/ intermediate locations via a manifest, so copying to bin/ is wasteful. The motivation is sound and well-justified.

Approach: Changing CopyToOutputDirectory from PreserveNewest to Never for all three categories of WASM build-time assets (webcil-converted, framework, and materialized framework) is the correct and minimal approach. Publish behavior is unaffected since CopyToPublishDirectory was already Never (publish uses its own pipeline). The test adjustment to skip bundle file assertions for build-only scenarios is the right companion change.

Summary: ⚠️ Needs Human Review. The core approach is correct and the code changes are clean. However, there is a stale comment that contradicts the new behavior and should be updated. Additionally, I've identified two existing tests that appear to directly inspect bin/_framework/ after build (not publish) — if satellite/resource assemblies go through the same DefineStaticWebAssets pipeline, those tests may break. The PR author is a codeowner of this area and may have already verified this, but a human reviewer should confirm.

Detailed Findings

⚠️ Stale Comment — XML comment contradicts code behavior

File: src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/build/Microsoft.NET.Sdk.WebAssembly.Browser.targets, lines 427–432

The XML comment still describes the old behavior:

<!-- ...Override both: AssetMode=All so assets flow through project references, and
     CopyToOutputDirectory=PreserveNewest so they are copied from the intermediate materialized
     path (obj/fx/{SourceId}/) to bin/wwwroot/_framework/ at build time. -->

But the code now sets CopyToOutputDirectory="Never" (line 435). The comment should be updated to reflect that assets are no longer copied to bin/wwwroot/_framework/ during build, and are instead served from obj/ locations via the static web assets middleware.

This is misleading for future maintainers who will read the comment and assume files are being copied when they aren't.

⚠️ Potential Test Breakage — Existing tests check bin/_framework/ after build

Two existing tests (not modified by this PR) directly inspect bin/_framework/ contents after a build (not publish):

1. SatelliteLoadingTests.SatelliteAssembliesFromPackageReference (SatelliteLoadingTests.cs:113):

   string binFrameworkDir = GetBinFrameworkDir(config, forPublish: false);
   // ... checks for satellite assembly directories in binFrameworkDir

2. Blazor/BuildPublishTests.DefaultTemplate_WithResources_Publish (BuildPublishTests.cs:100):

   AssertResourcesDlls(GetBlazorBinFrameworkDir(config, forPublish: false));

If satellite assemblies and project resource DLLs go through ConvertDllsToWebcil → _WebcilAssetsCandidates → DefineStaticWebAssets (which now sets CopyToOutputDirectory="Never"), these files would no longer be present in bin/_framework/ during build, and these tests would fail.

Low confidence flag: I'm not certain whether these specific asset types flow through the same pipeline modified by this PR. The PR author (@maraf) is a codeowner of this area and may have already verified this. A human reviewer should confirm whether these tests pass in CI.

✅ Correctness — Build/publish separation is correct

The IsPublish guard in WasmTemplateTestsBase.cs (line 262) correctly restricts bundle assertions to publish builds. BuildOptions.IsPublish defaults to false and PublishOptions.IsPublish defaults to true, so the assertion will fire exactly when expected. This aligns with the architecture: build uses the static web assets middleware (no files in bin/), publish physically copies files for deployment.

✅ Test Coverage — Build+run tests provide functional validation

Skipping AssertWasmSdkBundle for builds does lose file-layout assertions, but this is well-mitigated by the 25+ test files that build the app and then run it via RunForBuildWithDotnetRun → dotnet run --no-build. These tests validate that the static web assets middleware correctly serves framework files from obj/ locations. The runtime behavior is still thoroughly validated.

✅ Scope — Change is focused and consistent

All three CopyToOutputDirectory changes target the same logical pipeline (WASM build-time static web assets). CopyToPublishDirectory values are untouched. The commit is well-structured into two logical pieces: the targets change and the corresponding test adjustment.

💡 Comment Quality — Test comment could be more concise

The comment block in WasmTemplateTestsBase.cs (lines 258–261) is well-written and explains the "why" clearly. Minor suggestion: it could be shortened to 2 lines, but this is not blocking.

Generated by Code Review for issue #126407 · ◷