[browser] WebAssembly SDK targets more incremental

[maraf]

Summary

Improves MSBuild incrementalism for WebAssembly browser build targets in Microsoft.NET.Sdk.WebAssembly.Browser.targets. On no-op rebuilds where inputs have not changed, the expensive ConvertDllsToWebcil and GenerateWasmBootJson tasks are now skipped via MSBuild's Inputs/Outputs mechanism.

Changes

Webcil Conversion

Split _ResolveWasmOutputs into 3 targets:

• _ComputeWasmBuildCandidates (always runs) — resolves build asset candidates, classifies DLLs vs framework pass-throughs, computes expected webcil output paths
• _ConvertBuildDllsToWebcil (incremental) — runs ConvertDllsToWebcil only when DLL inputs are newer than webcil outputs
• _ResolveWasmOutputs (always runs) — reconstructs webcil items via MSBuild item transforms, classifies framework candidates, calls DefineStaticWebAssets

Boot JSON Generation

Split _GenerateBuildWasmBootJson into 3 targets:

• _ResolveBuildWasmBootJsonEndpoints (always runs) — resolves endpoints and fingerprinted assets
• _WriteBuildWasmBootJsonFile (incremental) — writes boot JSON file only when inputs change
• _GenerateBuildWasmBootJson (always runs) — defines static web assets from the boot JSON output

Split GeneratePublishWasmBootJson into 2 targets:

• _ResolvePublishWasmBootJsonInputs (always runs) — resolves publish endpoints
• GeneratePublishWasmBootJson (incremental) — writes boot JSON only when inputs change

Touch outputs for content-comparison tasks

Both ConvertDllsToWebcil (Utils.MoveIfDifferent) and GenerateWasmBootJson (ArtifactWriter.PersistFileIfChanged) use content-comparison write patterns that preserve old file timestamps when output content is unchanged. This defeats MSBuild's timestamp-based Inputs/Outputs incrementalism. Added <Touch> after each task invocation to ensure output timestamps reflect the current build session.

FileWrites in always-run wrapper targets

When incremental targets are skipped, <FileWrites> items inside their body are not populated. Added <FileWrites> to the always-run wrapper targets (_GenerateBuildWasmBootJson, _AddPublishWasmBootJsonToStaticWebAssets, _ResolveWasmOutputs) so dotnet clean works correctly.

Incrementalism Proof

Binlog analysis of Wasm.Browser.Sample — build 1 (clean) vs build 2 (no-op rebuild):

Build Path

Target                                   Build 1    Build 2    Status
----------------------------------------------------------------------
_ComputeWasmBuildCandidates                59ms       62ms     Runs (item producer, always needed)
_ConvertBuildDllsToWebcil                  60ms        7ms     ✅ SKIPPED — outputs up-to-date
_ResolveWasmOutputs                       138ms      116ms     Runs (DefineStaticWebAssets, item producer)
_ResolveBuildWasmBootJsonEndpoints         21ms       20ms     Runs (item producer)
_WriteBuildWasmBootJsonFile               104ms        4ms     ✅ SKIPPED — output up-to-date
_GenerateBuildWasmBootJson                  3ms        3ms     Runs (item producer)

Design Notes

Why split instead of just adding Inputs/Outputs?

MSBuild's Inputs/Outputs mechanism skips the entire target body when outputs are up-to-date. Since _ResolveWasmOutputs and _GenerateBuildWasmBootJson both contained file-writing tasks AND item-defining tasks (DefineStaticWebAssets), making them incremental would break downstream targets that depend on the items they produce. The split separates file I/O (incremental) from item definitions (always-run).

Why Touch after task execution?

Both ConvertDllsToWebcil and GenerateWasmBootJson implement "write only if content changed" patterns internally. While this avoids unnecessary downstream rebuilds, it defeats MSBuild's Inputs/Outputs check because unchanged outputs retain timestamps from a previous build session. The <Touch> ensures output timestamps always reflect the current build.

Framework asset classification

The Framework SourceType classification (from #125329) is preserved. Since the incremental _ConvertBuildDllsToWebcil target only receives DLL items, framework candidate classification is done in MSBuild item groups in _ComputeWasmBuildCandidates instead of via the task's PassThroughCandidates output. Items with WasmNativeBuildOutput metadata are per-project (Computed); items without are Framework assets needing per-project materialization.

Culture/non-culture DLL separation

Culture-specific DLLs have RelatedAsset metadata that non-culture DLLs lack. Using %(RelatedAsset) in item transforms causes MSB4096 batching errors. The fix uses separate intermediate items (_WasmWebcilConvertedNonCulture, _WasmWebcilConvertedCulture).

Testing

• Clean build and no-op rebuild succeed with zero errors
• No-op rebuild correctly skips _ConvertBuildDllsToWebcil and _WriteBuildWasmBootJsonFile
• Binlog analysis verified with MSBuild.StructuredLogger

Note

This PR description was generated with assistance from GitHub Copilot.

[Copilot]

Pull request overview

This PR improves MSBuild incrementalism for WebAssembly SDK build targets by splitting monolithic targets into smaller, more focused targets with proper Inputs/Outputs declarations. This allows MSBuild to skip expensive operations (webcil DLL conversion, boot JSON generation) on no-op rebuilds when inputs haven't changed.

Changes:

• The _ResolveWasmOutputs target is split into _ComputeWasmBuildCandidates (resolve/classify candidates), _ConvertBuildDllsToWebcil (incremental webcil conversion), and _ResolveWasmOutputs (reconstruct webcil metadata and define static web assets).
• The _GenerateBuildWasmBootJson target is split into _ResolveBuildWasmBootJsonEndpoints (resolve endpoints), _WriteBuildWasmBootJsonFile (incremental boot JSON generation), and _GenerateBuildWasmBootJson (define static web asset for boot config).
• The GeneratePublishWasmBootJson target is split into _ResolvePublishWasmBootJsonInputs (resolve inputs) and GeneratePublishWasmBootJson (incremental publish boot JSON generation).

[Copilot]

Pull request overview

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

---

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

Pull request overview

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

---

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[Copilot]

Same issue as the build stamp: the publish boot JSON stamp omits several non-file inputs that affect GenerateWasmBootJson output (notably @(WasmEnvironmentVariable) + %(Value), @(BlazorWebAssemblyLazyLoad), module lists, and WasmTest* properties). If any of these change without touching the listed file inputs, GeneratePublishWasmBootJson can be incorrectly skipped and keep a stale boot JSON. Consider incorporating these values into the stamp so incrementalism remains correct.

Suggested change

Lines="$(WasmDebugLevel)|$(_WasmPublishApplicationEnvironmentName)|$(_BlazorCacheBootResources)|$(InvariantGlobalization)|$(_LoadCustomIcuData)|$(_BlazorWebAssemblyLoadAllGlobalizationData)|$(_BlazorWebAssemblyJiterpreter)|$(_BlazorWebAssemblyRuntimeOptions)|$(RunAOTCompilation)|$(WasmEnableThreads)|$(_WasmFingerprintAssets)|$(_WasmBundlerFriendlyBootConfig)|$(WasmProfilers)|$(TargetFrameworkVersion)|$(DiagnosticPorts)"

Lines="$(WasmDebugLevel)|$(_WasmPublishApplicationEnvironmentName)|$(_BlazorCacheBootResources)|$(InvariantGlobalization)|$(_LoadCustomIcuData)|$(_BlazorWebAssemblyLoadAllGlobalizationData)|$(_BlazorWebAssemblyJiterpreter)|$(_BlazorWebAssemblyRuntimeOptions)|$(RunAOTCompilation)|$(WasmEnableThreads)|$(_WasmFingerprintAssets)|$(_WasmBundlerFriendlyBootConfig)|$(WasmProfilers)|$(TargetFrameworkVersion)|$(DiagnosticPorts)|@(WasmEnvironmentVariable->'%(Identity)=%(Value)', ';')|@(BlazorWebAssemblyLazyLoad, ';')|@(_WasmJsModuleCandidatesForPublish, ';')|@(_WasmJsModuleCandidatesForPublishEndpoint, ';')"

[maraf]

Note

This reply was generated by GitHub Copilot.

Fixed in the same commit (58d8153) — the publish stamp now includes the same additional inputs: @(WasmEnvironmentVariable->'%(Identity)=%(Value)'), @(BlazorWebAssemblyLazyLoad), @(WasmModuleAfterConfigLoaded), @(WasmModuleAfterRuntimeReady), and all WasmTest* properties.

[Copilot]

Pull request overview

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

[github-actions]

🤖 Copilot Code Review — PR #125367

Note

This review was generated by Copilot using multi-model analysis (Claude Opus 4.6 primary + Goldeneye sub-agent; GPT-5.3-Codex and Claude Sonnet 4.6 timed out).

Holistic Assessment

Motivation: The PR is well-justified — the WASM build targets were monolithic, causing unnecessary webcil conversion and boot JSON regeneration on every build even when nothing changed. MSBuild incrementalism is the standard solution.

Approach: The split into "resolve/compute inputs" (always-run) → "do work" (incremental with Inputs/Outputs) → "register outputs" (always-run) is the correct MSBuild pattern. Property stamp files for non-file inputs and Touch for content-comparison tasks are sound techniques.

Summary: ⚠️ Needs Human Review. The code is well-structured and the approach is correct. There are a few missing inputs in the incremental tracking that could cause stale outputs in edge cases. The test coverage validates the happy path but doesn’t exercise the property-change or culture-assembly scenarios. A human reviewer familiar with the WASM SDK should evaluate whether the missing inputs matter in practice.

---

Detailed Findings

✅ Target splitting pattern — Correct

The decomposition of monolithic targets is well-executed:

• _ComputeWasmBuildCandidates (always-run) → _ConvertBuildDllsToWebcil (incremental) → _ResolveWasmOutputs (always-run)
• _ResolveBuildWasmBootJsonEndpoints (always-run) → _WriteWasmBootJsonBuildPropertyStamp → _WriteBuildWasmBootJsonFile (incremental) → _GenerateBuildWasmBootJson (always-run)
• Same pattern for publish path

FileWrites are correctly tracked in always-run wrapper targets so dotnet clean works even when incremental targets are skipped.

✅ Touch pattern — Correct

Both _ConvertBuildDllsToWebcil and _WriteBuildWasmBootJsonFile use Touch after tasks that employ content comparison (MoveIfDifferent). This is necessary: without Touch, MSBuild would see old timestamps on unchanged outputs and re-run the target on the next build. The Condition="'@(_WasmConvertedWebcilOutputs)' != ''" guard on the webcil Touch prevents errors on empty output.

✅ UseWebcil guard — Correct

The guard is placed correctly. _ConvertBuildDllsToWebcil has Condition="'$(_WasmEnableWebcil)' == 'true'", so when webcil is disabled the target doesn’t appear in the binlog at all. The test guards in RebuildTests.cs correctly match the target’s Condition. This follows the same pattern used in WasmTemplateTests.cs.

The publish tests (IncrementalPublish_*) correctly do NOT need the guard — they only assert on GeneratePublishWasmBootJson, which runs regardless of webcil setting.

✅ CopyToPublishDirectory=Never filter — Correct

The filter correctly excludes build-only assets (e.g., HotReload DLL) from the publish pipeline. Without this, ComputeWasmPublishAssets could match them by filename and cause duplicate Identity crashes in multi-client hosted scenarios.

✅ Culture/non-culture DLL separation — Correct

The split into _WasmDllBuildCandidatesNonCulture and _WasmDllBuildCandidatesCulture correctly handles the MSBuild batching issue where RelatedAsset metadata only exists on culture items. The _ResolveWasmOutputs target mirrors this split for path reconstruction.

⚠️ Boot JSON stamp missing some non-file inputs — Advisory, follow-up

Flagged by: Goldeneye + primary reviewer

The property stamp files (wasm-bootjson-build.stamp, wasm-bootjson-publish.stamp) capture 15 properties but omit several inputs consumed by GenerateWasmBootJson:

• @(BlazorWebAssemblyLazyLoad) — item group for lazy loading
• @(WasmEnvironmentVariable) — environment variables
• @(WasmModuleAfterConfigLoaded) / @(WasmModuleAfterRuntimeReady) — JS module hooks
• WasmTest* properties: ExitOnUnhandledError, AppendElementOnExit, LogExitCode, AsyncFlushOnExit, ForwardConsole

Mitigating factors: Most of these are covered indirectly:

• Item groups set in the csproj are covered by $(MSBuildProjectFullPath) in Inputs
• Item groups computed by targets are covered by $(MSBuildThisFileFullPath) in Inputs
• WasmEnvironmentVariable is populated from $(DiagnosticPorts) which IS in the stamp
• WasmTest* properties are test-infrastructure-only and don’t change during normal development

The gap only manifests when these values change via /p: on the command line without any file changes. This is an uncommon development pattern, and the pre-PR behavior (always re-running) was worse. Consider tracking @(BlazorWebAssemblyLazyLoad) and @(WasmModuleAfter*) in the Inputs (as item groups) in a follow-up if lazy-load scenarios become important for incrementalism.

⚠️ _WasmWebcilVersion not tracked in webcil target Inputs — Advisory, follow-up

Flagged by: Goldeneye + primary reviewer

_WasmWebcilVersion is passed to ConvertDllsToWebcil but is not in the target’s Inputs list or a property stamp. If this property changes without any file modifications, the target would be skipped and produce stale webcil files.

Mitigating factor: _WasmWebcilVersion is computed from RuntimeFlavor (CoreCLR→1, Mono→0), which is fixed for a given build configuration. Changes via the csproj are covered by $(MSBuildProjectFullPath) in Inputs. This is unlikely to cause real-world issues, but a property stamp for _WasmWebcilVersion would make the incrementalism more robust.

💡 Test name mismatch — IncrementalPublish_NoChanges_SkipsWebcilAndBootJson

This test only asserts that GeneratePublishWasmBootJson is skipped — it does not verify any webcil target behavior. The name "SkipsWebcilAndBootJson" is misleading. Consider renaming to IncrementalPublish_NoChanges_SkipsBootJson for accuracy.

💡 Test coverage could be broader — Follow-up

All new tests use aot: false and don’t exercise:

• Culture/satellite assembly changes (the culture-split logic is new and untested)
• Property-stamp-triggered rebuilds (e.g., changing WasmDebugLevel between builds)
• Multi-project/hosted publish scenarios

The current tests validate the core incrementalism happy path (no-change skip, source-change rebuild), which is the most important case. The above scenarios would strengthen confidence but aren’t blocking.

Generated by Code Review for issue #125367 · ◷

[Copilot]

Pull request overview

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