[lewing]

Browser and WASI scenario projects stage shared tools (chrome, chromedriver, v8, wasmtime, ...) into the same artifacts/obj/helix-staging directory. sendtohelix.proj fans the scenario projects out with BuildInParallel=true (e.g. 4 BuildWasmApps variants), and each runs StageDependenciesForHelix from its InitialTargets. The !Exists(...) guard passes for all of them before any creates the directory, so they copy the same files concurrently. One project's Helix upload then zips chrome.dll while another is still writing it, which fails on Windows with a sharing violation ("locked by: MSBuild.dll").

Changes

• sendtohelix.proj: for browser/WASI when projects run in parallel, invoke StageDependenciesForHelix on each scenario project serially (with _StageHelixDependenciesOnly=true) before the parallel Test fan-out. The staging paths are version-keyed and identical across scenarios, so later projects see the completed directories and skip staging.
• sendtohelixhelp.proj: skip PrintHelixQueues, PrintBuildTargetFramework, and BuildHelixWorkItems (the InitialTargets) when _StageHelixDependenciesOnly=true, so the staging pass only copies files and doesn't build work items or print duplicate log lines.

Validation

• Ran ./dotnet.sh msbuild src/libraries/sendtohelixhelp.proj -t:StageDependenciesForHelix -p:TargetOS=browser -p:Scenario=BuildWasmApps -p:_StageHelixDependenciesOnly=true ... against fake tool directories: staging completed and the initial targets did not run. The same command without the property ran the initial targets as before.
• A mock parent/child project with the same structure confirmed that staging happens once in the serial pass and the parallel pass skips it.
• sendtohelix.proj preprocesses cleanly.
• I couldn't reproduce the race on macOS, which has no mandatory sharing locks, and haven't run this in Windows CI.

Fixes #136747

Note

This PR was generated with the assistance of GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
12 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/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[Copilot]

🔵 Needs a closer look

Mock-based validation does not exercise the Windows file-sharing failure, leaving the MSBuild serial-staging/parallel-upload handoff unconfirmed in real Windows browser/WASI CI.

No open issues 🎉

What changed in this PR

This PR addresses the shared-tool staging race behind #136747 by staging browser and WASI Helix dependencies serially before parallel scenario submissions.

Changes:

• Adds a serial dependency-staging pass when multiple browser or WASI scenario projects will run in parallel.
• Skips work-item creation and informational initial targets during staging-only runs, preserving normal submission behavior.

File	Description
src/​libraries/​sendtohelixhelp.proj	Guards work-item creation and logging targets with the staging-only property.
src/​libraries/​sendtohelix.proj	Stages dependencies serially before the parallel Test fan-out.

_{Review effort: Balanced}