[browser] Don't copy framework assets to output during build

[maraf]

Note

This PR was created with the assistance of GitHub Copilot.

Summary

During build, the WebAssembly SDK copies all .wasm and .js framework assets (~178 files) to bin/wwwroot/_framework/ via CopyToOutputDirectory=PreserveNewest. This is unnecessary because dotnet run uses the static web assets middleware, which serves files directly from their obj/ locations via the manifest (staticwebassets.runtime.json).

Changes

Set CopyToOutputDirectory=Never (was PreserveNewest) for three DefineStaticWebAssets / item-update calls in Microsoft.NET.Sdk.WebAssembly.Browser.targets:

• Webcil-converted assets (Computed source type) — the .wasm files produced from .dll
• Framework assets (Framework source type) — dotnet.js, dotnet.native.wasm, runtime JS, etc.
• Materialized framework assets (post-UpdatePackageStaticWebAssets) — the per-project copies in obj/fx/

Validation

• ✅ Build succeeds (dotnet build with TargetOS=browser)
• ✅ dotnet run starts WasmAppHost dev server correctly
• ✅ Playwright headless browser test confirms the WASM app loads and executes (outputs 42)
• ✅ bin/wwwroot/_framework/ drops from ~178 files to 2 (only hot-reload module + dotnet.js from a separate code path)
• ✅ CopyToPublishDirectory was already Never — publish is unaffected

Notes

• The previous PreserveNewest was added for Blazor WASM hosted scenarios where a server project serves the client's framework files. This scenario needs separate validation.
• Static web assets middleware resolves files from their source locations (obj/ dirs), so physical copies in bin/ are not needed for dotnet run.

Downstream impact: dotnet/sdk BlazorWasm test baselines

The Microsoft.NET.Sdk.BlazorWebAssembly.Tests StaticWebAssetsBaselines/*.Build.*.json files in dotnet/sdk currently assert that framework assets live under ${ProjectPath}\bin\Debug\${Tfm}\wwwroot\_framework\ after Build. Across the Build baselines there are ~1,940 bin\Debug references covering ~481 framework files:

• dotnet.* runtime/loader JS + .wasm + .map (+ .gz) — 12 files
• icudt_*.dat.gz — 3 files
• blazor.webassembly.js (+ .gz) — 2 files
• ~233 managed framework .wasm assemblies (+ .gz copies)
• Localized .resources.wasm satellites

Once this change flows to dotnet/sdk, these baselines will need to be regenerated so framework assets point at their intermediate/RestorePath locations instead of bin\. App-project outputs (blazorwasm.wasm/.pdb) and project references (RazorClassLibrary.*) are unaffected and remain under bin\.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

[github-actions]

🤖 Copilot Code Review — PR #126407

Note

This review was AI/Copilot-generated. Models used: Claude Opus 4.6 (primary), Claude Sonnet 4.5.

Holistic Assessment

Motivation: The PR addresses a genuine build performance issue — ~178 unnecessary file copies during build. The static web assets middleware already serves files from obj/ locations via the manifest, making the bin/wwwroot/_framework/ copies redundant during build. This is well-motivated.

Approach: The approach is clean and minimal — 3 attribute value changes in production code (CopyToOutputDirectory from PreserveNewest to Never), with the remaining 8 files being test adaptations. Publish behavior is unchanged. The approach is correct.

Summary: ⚠️ Needs Human Review. The production change and test updates are sound, but there are maintainability concerns (code duplication) and a minor test coverage reduction worth human judgment. No blocking correctness issues found.

---

Detailed Findings

✅ Production Change — Correct and well-scoped

The three changes in Microsoft.NET.Sdk.WebAssembly.Browser.targets correctly switch CopyToOutputDirectory from PreserveNewest to Never for:

• Webcil-converted assets (line 390, Computed static web assets)
• Framework pass-through candidates (line 409, Framework static web assets)
• Materialized framework assets (line 438, post-UpdatePackageStaticWebAssets)

The updated XML comments (lines 430–435) accurately describe the new behavior. CopyToPublishDirectory was already Never, and publish has its own copy mechanism, so publish is unaffected.

✅ New AssertBuildBundle method — Thorough validation

The new AssertBuildBundle method in WasmSdkBasedProjectProvider.cs (lines 205–309) is well-structured with clear sections for each asset category. It validates:

• Files exist in the correct obj/ subdirectories
• Files do NOT exist in wrong locations (obj root, bin/_framework/)
• Boot config is well-formed
• Native files match runtime pack when expected
• Multi-threaded worker files (added in review feedback)

The nullable isNativeBuild parameter flows correctly through GetExpectedFileType which handles all three states (true, false, null) with explicit comparisons.

⚠️ Code Duplication — "Discover fx subdirectory" pattern repeated 5 times

The following pattern appears verbatim in 5 locations across test files:

string fxBaseDir = Path.Combine(objDir, "fx");
string[] fxSubDirs = Directory.GetDirectories(fxBaseDir);
Assert.True(fxSubDirs.Length == 1,
    $"Expected exactly one subdirectory under {fxBaseDir}, ...");
string fxFrameworkDir = Path.Combine(fxSubDirs[0], "_framework");

Locations: WasmSdkBasedProjectProvider.AssertBuildBundle, BuildPublishTests.BuildThenPublishWithAOT, Blazor/BuildPublishTests.GetBuildSatelliteBaseDir, SatelliteLoadingTests.SatelliteAssembliesFromPackageReference, ModuleConfigTests.SymbolMapFileEmittedCore.

If the obj/ layout convention ever changes, all 5 places need updating in lockstep. Consider extracting a shared helper like GetMaterializedFrameworkDir(string objDir) on the provider base class. (Flagged by both review models.)

⚠️ NonDefaultFrameworkDir skips all build assertions — coverage gap

In AssertWasmSdkBundle (lines 187–192), when NonDefaultFrameworkDir is set and IsPublish is false, zero build bundle assertions run:

else if (string.IsNullOrEmpty(buildOptions.NonDefaultFrameworkDir))
{
    AssertBuildBundle(...);
}
// When NonDefaultFrameworkDir is set, skip build bundle assertions.

Before this PR, AssertBundle was called for all cases (including NonDefaultFrameworkDir). Tests like SimpleRunTests.BlazorBuildRunTest and WasmTemplateTests.BuildAndRunForDifferentOutputPaths pass NonDefaultFrameworkDir for non-artifacts builds too, so they now get no file-layout verification. The tests do verify the app runs via dotnet run, which is the primary concern, but the file-layout gap should be acknowledged. Would be worth at minimum logging a message when assertions are skipped to aid debugging.

💡 Minor: Duplicate Path.Combine in ModuleConfigTests.cs

In SymbolMapFileEmittedCore (lines 139–144), Path.Combine(objDir, "fx") is evaluated twice in the spread expression — once for Directory.Exists and once for Directory.GetDirectories. Extract to a local variable for clarity and consistency with the pattern used elsewhere.

💡 Minor: dotnet.native.worker.mjs not compared against runtime pack

In AssertBuildBundle, the multi-threaded worker file gets location assertions (exists in nativeDir, not in obj root) but is not compared against the runtime pack, unlike dotnet.native.js and dotnet.native.wasm. The publish-path AssertBundle has special-case handling that explicitly skips this comparison with an explanatory comment. Adding a similar comment in AssertBuildBundle would explain the intentional omission.

✅ Accidental symlink removal — Good cleanup

The deletion of src/mono/nuget/Microsoft.NET.Sdk.WebAssembly.Pack/WasmAppHost (a symlink pointing to a local Codespace path /workspaces/runtime/artifacts/bin/WasmAppHost/wasm/Debug) is appropriate cleanup that was caught in review.

✅ No public API changes detected

No changes to ref/ assemblies or new public API surface. All code changes are in MSBuild targets (build infrastructure) and test files.

Generated by Code Review for issue #126407 · ◷

[maraf]

Note

Comment authored with assistance from GitHub Copilot.

Thanks for the thorough pass. Addressing the findings in 00635ac + c6fe5e5:

✅ Code duplication (5× fx discovery) — extracted WasmSdkBasedProjectProvider.GetMaterializedFrameworkDir(objDir) and applied it at all 5 sites (AssertBuildBundle, BuildPublishTests.BuildThenPublishWithAOT, Blazor/BuildPublishTests.GetBuildSatelliteBaseDir, SatelliteLoadingTests.SatelliteAssembliesFromPackageReference, ModuleConfigTests.SymbolMapFileEmittedCore). Blazor/MiscTests.MultiClientHostedBuildAndPublish also switched to the helper (was previously hardcoding Client1/Client2).

✅ NonDefaultFrameworkDir skip — coverage gap — AssertWasmSdkBundle now emits a _testOutput.WriteLine when it skips AssertBuildBundle for NonDefaultFrameworkDir builds, so the skipped file-layout verification is visible in test logs. Keeping the skip itself for now since the obj/ layout genuinely diverges for UseArtifactsOutput; a proper layout check for that shape can be a follow-up.

✅ Duplicate Path.Combine(objDir, "fx") in ModuleConfigTests — hoisted into a fxBaseDir local.

✅ dotnet.native.worker.mjs runtime-pack comparison omission — added a comment in AssertBuildBundle explaining the intentional omission, mirroring the existing comment in the publish-path AssertBundle.

Left as-is:

• Hosted dotnet build + dotnet run server test (raised on Microsoft.NET.Sdk.WebAssembly.Browser.targets): out of scope for this PR. Hosted publish is still exercised end-to-end by MultiClientHostedBuildAndPublish; an end-to-end build + serve test would require new Kestrel + HTTP infra in Wasm.Build.Tests. Will file a follow-up issue.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

[maraf]

@javiercn Do we have scenario that would still rely on the actual files in the bin folder?

[maraf]

Note

This comment was generated with the assistance of GitHub Copilot.

CI analysis for the latest push (build 1388930):

• runtime: 12/13 green, 1 failed
• runtime-dev-innerloop: ✅ green
• dotnet-linker-tests: ✅ green

The single failure is browser-wasm linux Release CoreCLR_WasmBuildTests — Helix work item WBT-NoWorkload-CLR-ST-Wasm.Build.Tests.WasmRunOutOfAppBundleTests exited with code -4:

Unable to pull image mcr.microsoft.com/dotnet-buildtools/prereqs:ubuntu-26.04-helix-webassembly-amd64

This is the well-known Helix Docker-pull infrastructure flake tracked in #117164 — tests never started; the failing test (WasmRunOutOfAppBundleTests) doesn't exercise any code path touched by this PR. Unrelated to the change. Will retry with /azp run runtime if a fully green run is required before merge.