[browser] Wasm boot JSON: touch a stamp, not the boot JSON itself (fix #129280)

[lewing]

Problem

Wasm.Build.Tests.WasmTemplateTests.TypeScriptDefinitionsCopiedToWwwrootOnBuild(config: Debug, emitTypeScriptDts: True) fails its dotnet build -question rebuild check with:

MSBUILD : error : Building target "_BuildCopyStaticWebAssetsPreserveNewest" partially,
because some output files are out of date with respect to their input files.
[_BuildStaticWebAssetsPreserveNewest:
  Input  = obj\Debug\net11.0\compressed\{hash}-{0}-{fp}-{fp}.gz,
  Output = bin\Debug\net11.0\wwwroot\_framework\dotnet.{fp}.js.gz]
Input file is newer than output file.

This is the same family of bug as #129280 (different surface: upstream variant where MSBuild flags _WriteBuildWasmBootJsonFile itself as stale; ours is the downstream cascade through compression).

Root cause

Binlog analysis:

1. _WriteBuildWasmBootJsonFile runs GenerateWasmBootJson (uses ArtifactWriter.PersistFileIfChanged, preserves old mtime on unchanged content) followed by <Touch Files="$(_WasmBuildBootJsonPath)" /> (added in [browser] WebAssembly SDK targets more incremental #125367 to keep MSBuild's I/O check on this target happy).
2. $(_WasmBuildBootJsonPath) — obj/{cfg}/{tfm}/dotnet.js — is also a source for the StaticWebAssets compression pipeline (GenerateBuildCompressedStaticWebAssets → GZipCompress).
3. GZipCompress.cs skips when input.mtime < output.mtime (strict <). When Touch lands close enough in time to the .gz write (or any subsequent target re-stamps dotnet.js), equal/newer mtimes send the next build's compression task down the re-compress path.
4. Re-compression on build Get core-setup building in the consolidated repo. #2 bumps obj/.../{0}.gz mtime past bin/.../dotnet.{fp}.js.gz (which was copied during build WIP: repo consolidation scouting kick-off - make clr build locally on Windows #1 and isn't touched since), so _BuildCopyStaticWebAssetsPreserveNewest reports its input newer than its output. -question fails.

This is a regression of #118637 (Aug 2025, "Override boot config only when the content changes"), which fixed the exact same _BuildCopyStaticWebAssetsPreserveNewest symptom in dotnet/aspnetcore#63207 by introducing ArtifactWriter.PersistFileIfChanged. PR #125367's <Touch> undid that protection.

Fix

Touch a separate wasm-bootjson-{build,publish}.complete.stamp file rather than the boot JSON itself, and use the stamp as the target's Outputs=. MSBuild's incrementality check on the boot-JSON target stays correct (its declared output has a current mtime after every successful run), while the boot JSON's mtime remains content-derived — preserving #118637's invariant for downstream consumers.

Applied to both:

• _WriteBuildWasmBootJsonFile (build)
• GeneratePublishWasmBootJson (publish)

Both have identical shape and the same downstream consumers (StaticWebAssets compression / Copy targets).

What's not fixed here

• _ConvertBuildDllsToWebcil (line 431) uses the same <Touch> pattern but on per-item-batched @(_WasmConvertedWebcilOutputs). It is probably exposed to the same cascade for the webcil files; not addressed here pending a per-item analysis.
• Defense-in-depth in dotnet/sdk: GZipCompress/BrotliCompress < mtime check could become <= to harden the entire StaticWebAssets pipeline against this class of cascade. Worth a separate dotnet/sdk PR.

Verification

• Reproduces on dotnet/runtime PR [main] Source code updates from dotnet/dotnet #129454 build https://dev.azure.com/dnceng-public/public/_build/results?buildId=1470806 (browser-wasm windows Release WasmBuildTests, workitem WBT-NoWebcil-MONO-ST-Wasm.Build.Tests.WasmTemplateTests).
• The WBT theory case TypeScriptDefinitionsCopiedToWwwrootOnBuild(Debug|Release, emitTypeScriptDts:True) exercises the dotnet build -question second-build check that this fix addresses.

Fixes #129280

Note

This pull request was created with the assistance of GitHub Copilot.

[Copilot]

Pull request overview

This PR updates the WebAssembly Browser MSBuild targets to avoid touching the boot JSON itself (which can cascade timestamp changes into StaticWebAssets compression/copy), and instead uses a separate “complete” stamp file as the incremental Outputs= marker for boot JSON generation targets.

Changes:

• Switch _WriteBuildWasmBootJsonFile and GeneratePublishWasmBootJson to use wasm-bootjson-{build,publish}.complete.stamp as Outputs=.
• Touch the new stamp files (instead of the boot JSON) to satisfy MSBuild’s timestamp-based incremental checks.
• Track the new stamp files in FileWrites (note: build wrapper update suggested; publish wrapper update still needed).

[lewing]

Addressed in 97a975c — added wasm-bootjson-{build,publish}.complete.stamp to FileWrites in _GenerateBuildWasmBootJson and _AddPublishWasmBootJsonToStaticWebAssets so dotnet clean removes the stamps even when the incremental targets skip.

Note

This comment was AI/Copilot-generated.

[lewing]

Addressed in 97a975c — added wasm-bootjson-{build,publish}.complete.stamp to FileWrites in _GenerateBuildWasmBootJson and _AddPublishWasmBootJsonToStaticWebAssets so dotnet clean removes the stamps even when the incremental targets skip.

Note

This comment was AI/Copilot-generated.