Enable wasm-tools workload for CoreCLR WASM targets#130380
Merged
Merged
Conversation
Add a new 'wasm-tools-coreclr' workload that provides native relinking support for CoreCLR browser-wasm projects without pulling in Mono dependencies (MonoAOTCompiler, MonoTargets.Sdk, Mono runtime pack). Unlike Mono, CoreCLR doesn't need its runtime pack bundled in the workload — the SDK resolves it via the standard KnownRuntimePack mechanism. The workload only provides: - Build targets for native relinking (BrowserWasmApp.CoreCLR.targets) - Emscripten SDK (shared via microsoft-net-sdk-emscripten) Changes: - Package BrowserWasmApp.CoreCLR.targets into WebAssembly.Sdk NuGet pack - Add conditional import in Sdk.targets.in (UseMonoRuntime switches path) - Add wasm-tools-coreclr workload to manifest (no Mono deps) - Add CoreCLR import group in WorkloadManifest.targets.in - Skip MonoAOTCompiler import when UseMonoRuntime=false Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Guard the native.wasm.targets import with a condition so it only loads when RepositoryEngineeringDir is set (in-tree builds). For the workload path, inline the GenerateEmccExports target with the required exported runtime methods and functions. Emscripten SDK acquisition is already handled by EmSdkRepo.Defaults.props + the emscripten workload extension. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Include libminipal.a in browser-wasm CoreCLR runtime pack. It was excluded from LibrariesSharedFrameworkDir glob but unlike libz.a and libSystem.IO.Compression.Native.a it only exists in sharedFramework/ (not the parent LibrariesNativeArtifactsPath), so the exclusion prevented it from shipping at all. libminipal.a is a distinct library from libcoreclrminipal.a and is needed by the emcc linker. - Fix PInvokeTableGeneratorTests to use correct CoreCLR output filename callhelpers-pinvoke.cpp instead of pinvoke-table.cpp. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The _CoreCLRWasmNativeForBuild target must run before _ComputeWasmBuildCandidates (not just _ResolveWasmOutputs) so the relinked dotnet.native.wasm replaces the runtime pack version in the static web assets pipeline. Without this, the runtime pack binary is served and user P/Invoke modules fail with DllNotFoundException. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
During nested publish, _GatherWasmFilesToPublish populates WasmAssembliesToBundle from ResolvedFileToPublish (which includes app satellite assemblies). The CoreCLR build pipeline was calling _GatherWasmFilesToBuild which overwrites this list with build-time items that omit app satellites, causing ComputeWasmPublishAssets to fail. Introduce _CoreCLRGatherWasmFiles wrapper that skips _GatherWasmFilesToBuild during nested publish, preserving the publish-time assembly list. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Restore the exclusion of libminipal.a from the LibrariesSharedFrameworkDir glob. The file is already included via CoreCLRSharedFrameworkDir (line 111), so including it from both locations causes NU5118 duplicate file error during nupkg creation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the WebAssembly SDK/workload targets so wasm-tools can be used with CoreCLR browser-wasm builds (selecting CoreCLR vs Mono via UseMonoRuntime), and adjusts CoreCLR-specific build target behavior for workload vs in-tree usage. It also fixes a Wasm.Build.Tests expectation to match the CoreCLR pinvoke table output filename.
Changes:
- Route WebAssembly SDK target imports to
BrowserWasmApp.CoreCLR.targetswhenUseMonoRuntime=false, and package that targets file in the WebAssembly SDK pack. - Update the mono toolchain workload manifest to avoid importing Mono-specific packs/tasks when
UseMonoRuntime=false, and to import the WebAssembly SDK for CoreCLRbrowser-wasm. - Update CoreCLR browser-wasm targets to tolerate the workload (no in-tree
native.wasm.targets), adjust target ordering, and avoid a nested-publish satellite assembly overwrite. - Fix CoreCLR pinvoke table filename in
PInvokeTableGeneratorTests.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/mono/wasm/Wasm.Build.Tests/PInvokeTableGeneratorTests.cs | Updates the CoreCLR pinvoke table filename expectation to callhelpers-pinvoke.cpp. |
| src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.targets.in | Gates Mono-only workload imports on UseMonoRuntime != false and adds a CoreCLR browser-wasm import group for the WebAssembly SDK. |
| src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Sdk/Sdk.targets.in | Selects Mono vs CoreCLR browser targets based on UseMonoRuntime. |
| src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Microsoft.NET.Runtime.WebAssembly.Sdk.pkgproj | Packages BrowserWasmApp.CoreCLR.targets into the WebAssembly SDK. |
| src/mono/browser/build/BrowserWasmApp.CoreCLR.targets | Adds workload-safe guards and a fallback GenerateEmccExports, adjusts build/publish target ordering, and avoids nested-publish satellite assembly loss. |
Move native.wasm.targets import after the fallback GenerateEmccExports target so that when building in-tree, the authoritative definition in eng/native.wasm.targets wins (MSBuild last-definition-wins). For the workload path where native.wasm.targets is not available, the fallback list in BrowserWasmApp.CoreCLR.targets is used instead. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
3 tasks
Include the CoreCLR browser-wasm runtime pack in the wasm-tools workload manifest so it gets bundled and downloaded together with the other wasm-tools packs when the workload is installed. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
pavelsavara
approved these changes
Jul 9, 2026
This was referenced Jul 9, 2026
Open
Contributor
|
Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara |
Member
I guess this is some kind of chicken/egg problem ? |
…T legs The wasm-tools workload manifest now includes the CoreCLR browser-wasm runtime pack, so InstallWorkloadForTesting requires that pack in the local package feed. The Mono Wasm.Build.Tests legs only staged Mono packs, causing the workload install to fail with 'microsoft.netcore.app.runtime.browser-wasm is not found'. Add an opt-in includeCoreClrRuntimePack parameter to browser-wasm-build-tests that stages the CoreCLR runtime pack from the CoreCLR build artifact, enable it in runtime.yml, and add a CoreCLR browser-wasm build-only job to the extra-platforms wasm pipeline so its WBT leg can stage the pack too. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: fab61255-0f2b-4412-9a07-8eef5b99b3e0
Member
Author
needed to build and reference the packs on those legs |
This was referenced Jul 15, 2026
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
akoeplinger
approved these changes
Jul 16, 2026
lewing
added a commit
that referenced
this pull request
Jul 19, 2026
#131026) ## Summary Fixes the `runtime-wasm-perf` pipeline, which fails at **"Install workload using artifacts"** in the `browser-wasm linux Release wasm` (Mono) build job: ``` Version 11.0.0-ci of package microsoft.netcore.app.runtime.browser-wasm is not found in NuGet feeds ... ``` ## Root cause #130380 ("Enable wasm-tools workload for CoreCLR WASM targets") added the CoreCLR runtime pack `Microsoft.NETCore.App.Runtime.browser-wasm` to the `wasm-tools` workload manifest. The Mono perf build (`-s mono+libs+host+packs`) only produces the Mono runtime pack, and `packs` only builds the pack matching the build's `RuntimeFlavor` (`DotNetBuildAllRuntimePacks` even explicitly excludes CoreCLR for wasm). So the Mono job's local package feed never contains the CoreCLR pack the workload now requires, and the workload install fails. The `wasm_coreclr` job's install "succeeds" only because `_GetWorkloadsToInstall` lists workloads solely when `RuntimeFlavor == Mono`, making its install a no-op. #130380 already solved this for the main/extra-platforms CI by adding a **separate CoreCLR build + downloading its runtime pack** into the workload-install job (`includeCoreClrRuntimePack`). The perf pipeline was never given the same treatment. ## Fix The perf pipeline already builds both flavors in two jobs, so this reuses the existing CoreCLR pack instead of duplicating a build — mirroring the #130380 pattern: - **`perf-wasm-prepare-artifacts-steps.yml`** — two opt-in parameters: - `publishCoreClrRuntimePack`: the CoreCLR job publishes its `Microsoft.NETCore.App.Runtime.browser-wasm` nupkg as artifact `BrowserWasmCoreCLRRuntimePack_$(_hostedOs)`. - `downloadCoreClrRuntimePack`: the Mono job downloads it and stages it into `artifacts/packages/Release/Shipping/` **before** the workload install. - **`perf-wasm-build-jobs.yml`** — `wasm_coreclr` sets `publishCoreClrRuntimePack: true`; the `wasm` (Mono) job sets `downloadCoreClrRuntimePack: true` and `dependsOn: build_browser_wasm_linux_Release_wasm_coreclr`. The staged CoreCLR pack doesn't interfere with the Mono job's existing `_GetRuntimePackNuGetsToBuild` logic (which only matches `Microsoft.NETCore.App.Runtime.Mono.*`), and only the net11/Current manifest requires this pack, so the `11.0.0-ci` pack from the same commit satisfies it. ## Tradeoff The Mono build now depends on the CoreCLR build (previously parallel), adding wall-clock to this PR-triggered sanity pipeline. The alternative — building `clr` inside the Mono job — doesn't work cleanly because no single build produces both wasm runtime packs, and duplicating the full CoreCLR build is heavier. The download approach matches the established #130380 pattern. > [!NOTE] > This PR was generated with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contributes to #126100
Summary
Enables the existing
wasm-toolsworkload to function with CoreCLR WASM targets, allowing native relinking and future AOT compilation via the same workload that Mono users already install.Changes
SDK/Targets
BrowserWasmApp.CoreCLR.targetswhenRuntimeFlavor=CoreCLR_ComputeWasmBuildCandidatesbefore native relink); fix satellite assembly handling during nested publishWasmNativeWorkload=truefor CoreCLR path when workload is installedBrowserWasmApp.CoreCLR.targetsin SDK packageTest Fix
callhelpers-pinvoke.cppnotpinvoke-table.cpp)Architecture
Unlike Mono, CoreCLR does not need its own workload definition. The existing
wasm-toolsworkload already contains the WebAssembly SDK and Emscripten packs that CoreCLR needs. The SDK targets detectRuntimeFlavorand import the correct.targetsfile. CoreCLR runtime packs are resolved by the SDK viaKnownRuntimePack.Related
Note
This PR was generated with the assistance of GitHub Copilot.