[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

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

[pavelsavara]

Does change of (wasm related) properties force full rebuild ?