[browser] Native build on CoreCLR in Wasm.Build.Tests

[maraf]

Note

This PR description was AI-generated (GitHub Copilot CLI).

Enables per-app native relink of Wasm apps built on CoreCLR inside the Wasm.Build.Tests suite on Helix, and seeds a small subset of native tests that exercise the new plumbing.

What changes

1. Pack CoreCLR WBT native-build files as Helix payload (2bdd66268d8)

• Ship eng/native.wasm.targets and eng/AcquireEmscriptenSdk.targets alongside BrowserBuildTargetsDir so the BrowserWasmApp.CoreCLR.targets import chain resolves on Helix workers.
• Hoist Microsoft.NET.Sdk.WebAssembly.Pack (WasmSdkTargets / WasmSdkTools) out of the Mono-only correlation-payload block into the shared NeedsEMSDK block — the wasmbrowser template needs the WebAssembly SDK regardless of runtime flavor.
• Export REPOSITORY_ENGINEERING_DIR, EMSDK_PATH, WASM_BUILD_SUPPORT_DIR, WASM_APP_BUILDER_DIR from the generated RunScriptTemplate.{sh,cmd} and bridge them through BuildEnvironment / EnvironmentVariables so local dotnet test runs outside Helix still find the locally built targets/emsdk.

2. Introduce native-coreclr WBT category and enable first test class (1c405ae1e7f)

All tests tagged [TestCategory("native")] are excluded on CoreCLR by Wasm.Build.Tests.csproj's trait filter (-notrait category=native -notrait category=mono -notrait category=workload). Adding the same test to [TestCategory("native-coreclr")] does not work because class + method trait values merge — -notrait category=native still excludes a test that has both tags.

• Replace class-level [TestCategory("native")] with [TestCategory("native-coreclr")] on Wasm.Build.Templates.Tests.NativeBuildTests (2 [Theory] methods, all aot: false, exercising native relink via the wasmbrowser template).
• Add the class to eng/testing/scenarios/BuildWasmAppsJobsListCoreCLR.txt.
• No csproj filter change needed: the existing CoreCLR filter passes native-coreclr through naturally, and Mono's xunit invocation has no category=native* filter, so Mono coverage is unchanged.

3. [DO NOT MERGE] runtime.yml: trim to WBT-only for PR testing (e0b758c7bc3)

Scratch pipeline change to accelerate iteration. Keeps only the 5 jobs needed for Mono + CoreCLR WBT (CoreCLR runtime-pack build, CoreCLR WBT runner, Mono SingleThreaded + MultiThreaded build-only, Mono WBT runner) with alwaysRun: true. Revert before merging.

Validation

• Local build: ./dotnet.sh build src/mono/wasm/Wasm.Build.Tests/Wasm.Build.Tests.csproj -c Release /p:TargetOS=browser /p:RuntimeFlavor=CoreCLR /p:Scenario=BuildWasmApps → 0W/0E.
• Generated RunTests.sh inspected: xunit trait arg still -notrait category=native … (excludes native, lets native-coreclr through); env-var exports present with concrete paths.
• strings on Wasm.Build.Tests.dll confirms both native and native-coreclr category literals are baked in.
• Helix end-to-end validation pending this PR's CI.

Follow-up (not in this PR)

• Enable a broader set of native tests on CoreCLR by retagging non-AOT methods in mixed AOT/non-AOT classes (Wasm.Build.Tests.NativeBuildTests, NativeLibraryTests, PInvokeTableGeneratorTests, DllImportTests).

[dotnet-policy-service]

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

[maraf]

Note

This comment was generated with GitHub Copilot assistance.

@pavelsavara — summary of CoreCLR NativeBuildTests failures on this PR's latest run (build 1389073), after the template-install fix landed.

1. __GeneratedInitializer TypeLoad (root cause confirmed)

The JSImport Roslyn source generator (JSExportGenerator.cs:192) emits System.Runtime.InteropServices.JavaScript.__GeneratedInitializer only when the assembly contains [JSImport]/[JSExport]. The test asset src/mono/wasm/testassets/marshal_ilgen_test.cs uses only [DllImport], so the type is never generated.

I verified this locally by building the test's Program.cs with a fresh dotnet new wasmbrowser and dumping the IL — the assembly contains only Program and MyClass, no __GeneratedInitializer:

$ ildasm repro.dll | grep "^\.class"
.class private auto ansi beforefieldinit Program
.class public auto ansi beforefieldinit MyClass

The wasmbrowser template's default wwwroot/main.js calls await getAssemblyExports(config.mainAssemblyName) (UpdateBrowserMainJs does not remove this line — it only tweaks .create() options and runMainAndExit). That routes to JSHostImplementation.BindAssemblyExports, and the two runtime flavors diverge:

	Path	When assembly has no JSExports
Mono	JSHostImplementation.Mono.cs → Interop.Runtime.BindAssemblyExports (native)	Tolerant, no-ops
CoreCLR	JSHostImplementation.CoreCLR.cs:23 → assembly.GetType("…__GeneratedInitializer", throwOnError: true)	Throws TypeLoad

Proposed fix

In src/libraries/System.Runtime.InteropServices.JavaScript/src/System/Runtime/InteropServices/JavaScript/JSHostImplementation.CoreCLR.cs, use throwOnError: false and early-return if the type is null (matching Mono semantics — legitimate for assemblies with no [JSExport]):

Type? generatedInitializerType = assembly.GetType(
    "System.Runtime.InteropServices.JavaScript.__GeneratedInitializer",
    throwOnError: false);
if (generatedInitializerType is null)
    return Task.CompletedTask;

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

[Copilot]

The HelixDependenciesToStage ItemGroup is now conditioned on $(EMSDK_PATH) != ''. If NeedsEMSDK is true but EMSDK_PATH isn’t set (and the provisioned emsdk directory isn’t present), this will skip staging entirely and can lead to harder-to-diagnose Helix payload failures later. Consider keeping the item unconditionally when NeedsEMSDK/IncludeNodePayload is true and letting StageDependenciesForHelix emit its clear error, or add an explicit <Error> when NeedsEMSDK is true and $(EMSDK_PATH) is empty.

[github-actions]

🤖 Copilot Code Review — PR #127073

Note

This review was generated by Copilot and reflects automated analysis — not a human reviewer. Models contributing: Claude Opus 4.6 (primary), Claude Sonnet 4.5.

Holistic Assessment

Motivation: Justified and well-scoped. CoreCLR is gaining WASM support and needs the same build-test coverage that Mono already has. Extending the existing WBT infrastructure to CoreCLR is the right time to do this — before the test gap widens.

Approach: Sound. The PR extends the existing Mono WBT framework rather than duplicating it, with clean RuntimeFlavor == 'CoreCLR' guards. The env-var bridge between Helix payload locations and MSBuild properties follows the established pattern used by Mono WBT. The commit history shows careful iterative debugging of Helix pipeline issues (emsdk provisioning, evaluation-time staging, payload format, template installation).

Summary: ✅ LGTM. No blocking issues found. The changes are well-documented, defensively coded, and properly gated. The [DO NOT MERGE] scratch commits are cleanly reverted. Minor suggestions below are non-blocking.

---

Detailed Findings

✅ AcquireEmscriptenSdk.proj Fix — Correct

The old <Target Name="Build" DependsOnTargets="AcquireEmscriptenSdkUnconditional" /> was being shadowed by Microsoft.Build.NoTargets's own Build target, so ./build.sh -s provision.emsdk was silently a no-op. The BeforeTargets="Build" hook is the right fix and the comment explains the rationale clearly.

✅ Helix Payload Separation — Well-Structured

The split of HelixCorrelationPayload items into shared (emsdk, WasmAppBuilder, BrowserBuildTargetsDir, WasmSdkTargets/Tools) vs Mono-only (MonoAOTCompiler, runtime pack, MonoTargetsTasks, cross tools) is correct. CoreCLR acquires its runtime pack via nupkg on the Helix worker, so shipping the raw layout is unnecessary.

The eng/*.targets staging into a directory (rather than individual files) correctly avoids the Helix client's "unzip as archive" behavior — good catch.

✅ EMSDK Evaluation-Time Staging — Correct

Moving HelixDependenciesToStage from a target to project-evaluation scope is necessary because StageDependenciesForHelix evaluates its @(HelixDependenciesToStage) condition before BeforeTargets hooks run. The '$(EMSDK_PATH)' != '' guard is safe because:

• sendtohelix-browser.targets imports AcquireEmscriptenSdk.targets at line 32
• That import sets $(EMSDK_PATH) in a <PropertyGroup> (evaluation-time, not target-time) when $(ProvisionEmscriptenDir) exists
• For both Mono and CoreCLR agents, the emsdk directory exists before sendtohelix runs

✅ Windows Parity — No Gap

RunScriptTemplate.sh adds export statements for CoreCLR env vars in set_env_vars(), but RunScriptTemplate.cmd has no equivalent. This is correct — in bash, export is needed to propagate shell variables to child processes; in cmd.exe, variables set via set are automatically inherited. The HelixPreCommand items (lines 163-168 of sendtohelix-browser.targets) set these vars for Windows Helix, and RunScriptCommands in the csproj generate set VAR=value for local runs.

✅ NativeBuildTests Exclusion — Clean

The tests are excluded on CoreCLR via the existing category=native trait filter (-notrait category=native in _XUnitTraitArg). The comments document the specific product-level reasons (WasmAllowUndefinedSymbols not honored, getAssemblyExports throwOnError difference). Good approach — excludes at the category level rather than per-method ConditionalFact.

✅ Template Installation — Well-Implemented

EnsureWasmTemplatesInstalled() handles:

• Double-checked locking for thread safety (safe on .NET CLR memory model)
• Isolated DOTNET_CLI_HOME to prevent cross-job collisions on Helix
• Propagation of the harness's EnvVars to the install process
• 120-second timeout with process tree kill and output capture
• Symbols nupkg filtering

💡 Missing Trailing Newline — Local.Directory.Build.props

The file ends without a trailing newline (hex dump shows final byte is >). While not functionally breaking, this produces \ No newline at end of file in diffs and can cause issues with some tools. Consider adding a final newline.

💡 Double-Checked Locking Strictness

s_wasmTemplatesInstalled is read outside the lock without volatile or Volatile.Read. On the .NET CLR memory model (and all current architectures), this works correctly — the lock provides the necessary memory barrier. Strictly per ECMA-335, Volatile.Read would be more correct for the fast-path check. Extremely low priority; mentioning only for completeness.

---

Models: Claude Opus 4.6 (primary), Claude Sonnet 4.5. The GPT-5.3-Codex agent did not complete within the 10-minute timeout and was not included.

Generated by Code Review for issue #127073 · ◷