Summary

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

Changes

Boot JSON Generation (commit 1)

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

Webcil Conversion (commit 2)

Split _ResolveWasmOutputs into 3 targets:

• _ComputeWasmBuildCandidates (always runs) -- resolves build asset candidates via ComputeWasmBuildAssets
• _ConvertBuildDllsToWebcil (incremental) -- runs ConvertDllsToWebcil only when DLL inputs are newer than webcil outputs
• _ResolveWasmOutputs (always runs) -- reconstructs webcil items via MSBuild item transforms and calls DefineStaticWebAssets

Touch outputs for content-comparison tasks (commit 4)

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 — on no-op rebuilds, output files retained timestamps from a previous build session while input files had timestamps from the current session, causing MSBuild to always see inputs as newer than outputs.

Added <Touch> after each task invocation to ensure output timestamps reflect the current build session:

• _ConvertBuildDllsToWebcil: Touch @(_WasmExpectedWebcilOutputs)
• _WriteBuildWasmBootJsonFile: Touch $(_WasmBuildBootJsonPath)
• GeneratePublishWasmBootJson: Touch $(IntermediateOutputPath)$(_WasmPublishBootConfigFileName)

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                40ms       55ms     Runs (item producer, always needed)
_ConvertBuildDllsToWebcil                  54ms        6ms     ✅ SKIPPED — outputs up-to-date
_ResolveWasmOutputs                        86ms       92ms     Runs (DefineStaticWebAssets, item producer)
_ResolveBuildWasmBootJsonEndpoints         14ms       17ms     Runs (item producer)
_WriteBuildWasmBootJsonFile                99ms        3ms     ✅ SKIPPED — output up-to-date
_GenerateBuildWasmBootJson                  3ms        3ms     Runs (item producer)

Publish Path

Target                                   Publish 1  Publish 2  Status
----------------------------------------------------------------------
GeneratePublishWasmBootJson                92ms        0ms     ✅ SKIPPED — output up-to-date
ProcessPublishFilesForWasm                 90ms      100ms     Runs (not yet split — future opportunity)

Overall

• Build time reduction: Clean build 26s → No-op rebuild 5s (81% reduction)
• Third consecutive rebuild: 7s — confirms convergent incrementalism

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 is good for avoiding unnecessary downstream rebuilds in the general case, 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, allowing MSBuild to correctly determine that outputs are up-to-date on subsequent no-op builds.

MSBuild Condition evaluation order

_ConvertBuildDllsToWebcil has Condition="'$(_WasmEnableWebcil)' == 'true'" but MSBuild evaluates Condition before DependsOnTargets. Since _WasmEnableWebcil is set by _ResolveWasmConfiguration (inside _ComputeWasmBuildCandidates), the parent _ResolveWasmOutputs explicitly lists _ComputeWasmBuildCandidates in its DependsOnTargets before _ConvertBuildDllsToWebcil.

Culture/non-culture DLL separation

Non-culture DLLs and culture-specific DLLs have different metadata (RelatedAsset only exists on culture items). Using %(RelatedAsset) in item transforms causes MSB4096 batching errors when applied to items without that metadata. The fix uses separate intermediate item names (_WasmWebcilConvertedNonCulture, _WasmWebcilConvertedCulture) to avoid cross-contamination.

Testing

• Clean build and publish succeed with zero errors
• No-op rebuild correctly skips _ConvertBuildDllsToWebcil, _WriteBuildWasmBootJsonFile, and GeneratePublishWasmBootJson
• Third consecutive rebuild confirms convergent incrementalism (targets stay skipped)
• Binlog analysis verified with MSBuild.StructuredLogger