[perf][wasm] fix wasm-perf lane, stage complete CoreCLR toolchain cohort

[lewing]

Summary

Stage the complete same-build CoreCLR browser-WASM package cohort consumed by the performance pipeline. This fixes two failures:

• The Mono artifact job now downloads both the CoreCLR browser runtime pack and Crossgen2 pack before installing the wasm-tools workload. In runtime-wasm-perf build 1584559, workload installation failed because Microsoft.NETCore.App.Crossgen2.linux-x64 version 11.0.0-ci was absent from the local feed.
• The CoreCLR R2R artifact now includes the locally built Microsoft.NET.ILLink.Tasks package. In build 1581666, restore requested ILLink product version .109, the artifact did not contain it, NuGet floated to .118, and _RunILLink then failed because the payload only contained the .109 runtime.

The existing CoreCLR-only Crossgen2 staging switch becomes one toolchain/cohort staging switch that:

• packs ILLink.Tasks.csproj without rebuilding or restoring, because the normal clr+libs+host+packs build compiles the project but does not pack it;
• requires exactly one non-symbol package for each local package ID;
• rejects packages whose versions do not match the local WebAssembly SDK cohort;
• publishes the CoreCLR runtime and Crossgen2 packs for the dependent Mono artifact job;
• stages those packages into the Mono job's local feed before workload installation.

This completes the runtime artifact consumed by dotnet/performance#5297 and repairs the prerequisite artifact build used by the existing Mono WASM performance lane.

Complete staged cohort

The CoreCLR performance artifact now carries the complete same-build publish inputs:

• SDK: staging/dotnet-none
• CoreCLR browser runtime pack: staging/microsoft.netcore.app.runtime.browser-wasm
• Microsoft.NETCore.App.Ref
• Microsoft.NET.Sdk.WebAssembly.Pack
• Microsoft.NETCore.App.Crossgen2.linux-x64
• Microsoft.NET.ILLink.Tasks

The dependent Mono artifact job also receives the same-build CoreCLR browser runtime and Crossgen2 packages before installing its workload. WebAssembly SDK and ILLink are direct SDK tool restore dependencies, while Crossgen2 and the runtime/ref packs are selected through the SDK framework/tool-pack graph. ILLink's private dependencies are included in its tooling package, so no additional locally built SDK tool package is required. The performance-side override aligns KnownWebAssemblySdkPack, KnownCrossgen2Pack, and KnownILLinkPack to the staged local package version.

Validation

• Parsed both changed Azure Pipelines YAML files.
• Simulated the extracted staging script with matching non-symbol, symbol, and unrelated nupkgs; only the required non-symbol cohort packages were selected.
• Simulated an absent package and a mismatched package version; both failed with explicit diagnostics.
• Audited build 1584559 and confirmed the Mono artifact job failed specifically because Microsoft.NETCore.App.Crossgen2.linux-x64 version 11.0.0-ci was missing from the local package feed; this change publishes and downloads that exact package from the CoreCLR build job.
• Audited build 1581666's restore/publish binlogs and CoreCLR build artifact. This confirmed the NU1603 fallback, the .118 ILLink/runtime mismatch, the package graph above, and that the regular runtime build compiles but does not pack ILLink.Tasks.csproj.
• Ran git diff --check and an independent focused review of the final pipeline diff.

Remaining end-to-end validation

Queue runtime-wasm-perf pipeline 156 on Ubuntu 22.04 with repository resource overrides:

{
"resources": {
"repositories": {
"self": { "refName": "refs/heads/lewing-stage-wasm-r2r-tools" },
"performance": { "refName": "refs/heads/lewing-wasm-coreclr-r2r-perf" }
}
}
}

The Mono artifact job must install the workload from the local feed without a missing Crossgen2 package. The CoreCLR R2R lane must restore without NU1603/fallback, complete ILLink, emit non-empty per-app R2R images through Crossgen2, stage WebCIL, and start the benchmark under V8. Existing failed builds cannot provide that proof because their published artifacts predate the complete cohort staged by this change.

Note

This pull request description was generated with the assistance of GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 6 pipeline(s).
10 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

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

[azure-pipelines]

Azure Pipelines:
Successfully started running 6 pipeline(s).
10 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🟢 Approval recommended

The change is localized to perf pipeline artifact staging and appears consistent with existing template usage, with only a minor diagnostic-message clarity nit identified.

Pull request overview

Stages a complete same-build NuGet cohort for CoreCLR browser-WASM performance artifacts by packing Microsoft.NET.ILLink.Tasks and (optionally) staging/validating the CoreCLR R2R toolchain packages alongside the existing SDK/runtime/ref inputs.

Changes:

• Replace the CoreCLR-only Crossgen2 staging switch with a single includeCoreClrToolchainPacks switch and add an explicit dotnet pack step for ILLink.Tasks.csproj (no build/restore).
• Add a staging script that enforces “exactly one non-symbol nupkg” per required package ID and verifies all selected packages share the same cohort version.
• Update the CoreCLR wasm perf job to enable the new toolchain/cohort staging switch.

File summaries

File	Description
eng/pipelines/performance/templates/perf-wasm-prepare-artifacts-steps.yml	Adds ILLink packing plus cohort selection/version validation and stages CoreCLR toolchain packs when enabled.
eng/pipelines/performance/templates/perf-wasm-build-jobs.yml	Switches the CoreCLR job to use includeCoreClrToolchainPacks: true.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

The new ILLink pack step is configured as --no-build --no-restore even though the job’s main build subset doesn’t build tools.illink, making the pipeline likely to fail.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

[lewing]

Follow-up: case-sensitive per-app R2R staging

Combined runtime-wasm-perf build 1583407 reached the complete local package cohort, ILLink, and per-app Crossgen2 compilation, then failed on Linux while converting R2R/Azure.Core.dll to WebCIL.

The publish binlog showed the mismatch:

• SDK producer: _ReadyToRunOutputPath=.../R2R
• WASM WebCIL consumer: _WasmPublishR2RDir=.../r2r/

On a case-sensitive filesystem the consumer missed the generated image and attempted to convert the R2R .dll itself as ordinary PE/WebCIL, producing Unknown file format.

Commit b18dbfa9566 now uses the canonical SDK R2R spelling. The same property feeds trimmed build/publish prebuilt directories and their incremental stamp inputs.

Validation:

• ./build.sh mono+libs: succeeded, 0 warnings/errors.
• Added PublishReadyToRunDirectoryMatchesSdkOutputCasing, which compares the evaluated path ordinally.
• Against build 1583407's unfixed .ci WebAssembly package: failed as expected (R2R/ vs r2r/).
• Against a scratch package containing only this target fix: passed (1/1).
• No-workload Wasm.Build.Tests build: succeeded, 0 warnings/errors.
• Direct target evaluation, target XML parsing, and git diff --check: succeeded.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

🟡 Changes recommended

The pipeline step uses dotnet pack --no-build for ILLink.Tasks, which isn’t guaranteed to have been built by the clr+libs+host+packs subset and can make the artifact staging fragile.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (1)

eng/pipelines/performance/templates/perf-wasm-prepare-artifacts-steps.yml:64

• dotnet pack --no-build assumes ILLink.Tasks.csproj was already built in this job. However, eng/Subsets.props only schedules ILLink.Tasks.csproj under the +tools.illink+ subset, which is not part of the clr+libs+host+packs subset used by the CoreCLR wasm build job. This makes the artifact staging brittle: if the project wasn't built as a transitive dependency, pack --no-build can fail due to missing outputs.

Consider dropping --no-build (keep --no-restore) so packing can build incrementally when needed without re-restoring.

 # The WebAssembly SDK, ref, and host tool packages form the complete local product cohort
# consumed by a trimmed CoreCLR R2R publish.
- ${{ if eq(parameters.includeCoreClrToolchainPacks, true) }}:
- script: >-
./dotnet.sh pack --no-build --no-restore

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

It changes CI/perf artifact staging and MSBuild target behavior for CoreCLR wasm R2R, which has a high blast radius and should be validated by a human via an end-to-end pipeline run.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

The new test currently relies on default target scheduling despite testing publish-only properties, which risks flakiness unless it explicitly runs the target that computes/prints _WasmPublishR2RDir.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Lite

[lewing]

Follow-up: complete CoreCLR-to-Mono workload handoff

Combined build 1583669 validated the CoreCLR side end-to-end: the artifact build, JIT lane, and R2R lane all passed. The Mono artifact job then failed in InstallWorkloadUsingArtifacts because Microsoft.NETCore.App.Crossgen2.linux-x64 version 11.0.0-ci was absent from both remote feeds and its local Shipping feed.

The current wasm-tools manifest requires two CoreCLR-only packages that the Mono build cannot produce:

• Microsoft.NETCore.App.Runtime.browser-wasm
• Microsoft.NETCore.App.Crossgen2.<host RID>

Commit e8f1664091b changes the CoreCLR-to-Mono handoff from a runtime-pack-only artifact to that complete workload package closure. A shared staging helper enforces exactly one non-symbol package per pattern and one package version across the closure. The Mono consumer revalidates the downloaded pair and verifies its version matches the locally built Microsoft.NET.Sdk.WebAssembly.Pack cohort before copying both into Shipping.

Validation:

• Parsed both changed Azure Pipelines YAML templates.
• Parsed the shared bash helper with bash -n.
• Simulated the CoreCLR benchmark cohort, producer handoff, and Mono consumer using matching non-symbol, symbol, and unrelated nupkgs.
• Verified exact staged sets: four non-symbol benchmark packages; two non-symbol handoff packages.
• Verified explicit failure for missing, duplicate, internally mismatched, and cross-job version-mismatched packages.
• Audited the manifest closure and existing browser-WASM build-test precedent, which independently hands off the same runtime and Crossgen2 package families.
• A local workload install is not representative on this macOS host because build 1583669's package closure is linux-x64; the new PR-to-PR runtime-wasm-perf run is the authoritative install validation.

Note

This comment was generated with the assistance of GitHub Copilot.

[Copilot]

🔵 Needs a closer look

It changes artifact composition and Azure Pipelines staging logic for perf workloads, which has a high blast radius and can’t be fully validated here without an end-to-end pipeline run.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

The changes are cohesive, parameter rename/update is consistent across templates, and the behavioral change (R2R dir casing) is covered by a focused test.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 0 new
• Review effort level: Lite

[lewing]

green run againt this and dotnet/performance#5297 here https://dev.azure.com/dnceng-public/public/_build/results?buildId=1584001&view=results

[lewing]

@radekdoulik this is now required after the workload changes in the thunk generator.