Repository navigation
Add emsdk RepositoryReference to runtime for browser builds - #8193
Merged
akoeplinger merged 7 commits intoAug 11, 2026
Merged
akoeplinger merged 7 commits into
akoeplinger merged 7 commits into
Conversation
The browser (WebAssembly) runtime build needs the Emscripten toolchain from emsdk. Add a browser-gated RepositoryReference from runtime to emsdk so emsdk source changes are consumed by the runtime browser build in the same vertical. emsdk is a host build tool, so its build is overridden to target the host OS/architecture/RID even though the vertical keeps TargetOS=browser. Co-authored-by: Copilot <[email protected]> Copilot-Session: 9ffabacd-e239-4bbc-9f9f-8ff2cc616bae
|
Azure Pipelines: Successfully started running 1 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
There was a problem hiding this comment.
Pull request overview
Adds emsdk as a dependency of the runtime repo build when building the browser (WebAssembly) vertical, and adjusts the emsdk repo-project to build for the host toolchain even when the outer vertical target is browser.
Changes:
- Add a browser-gated
RepositoryReferencefromruntimetoemsdk. - In
emsdk.proj, append host-targeting properties to the repo build args for the browser vertical.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| repo-projects/runtime.proj | Adds emsdk as a browser-only dependency so runtime browser builds consume emsdk changes in the same vertical. |
| repo-projects/emsdk.proj | Overrides target properties during browser vertical builds so emsdk is built for the host toolchain. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
The VMR-level $(BuildRid) can be distro-specific (e.g. azurelinux.3.0-x64), which made emsdk look for runtime.azurelinux.3.0-x64.Microsoft.NETCore.Runtime.Wasm.*.Transport packages that only exist for portable RIDs, failing with NU1101. It also made TargetRid != emsdk's own portable BuildRid, so emsdk treated it as a cross-build. Co-authored-by: Copilot <[email protected]> Copilot-Session: 9ffabacd-e239-4bbc-9f9f-8ff2cc616bae
Now that runtime references emsdk in repo-projects, the browser build should consume the emsdk built alongside it in the same vertical. It didn't: runtime's EmsdkPackageVersion was set to MicrosoftNETCoreAppRefPackageVersion, which is a Version.Details.xml dependency version, so NuGet restored a previously published emsdk from the remote feed instead of the one this build just produced. The reason for that workaround is that every package emsdk produces has both the Emscripten version and the RID in its ID, so there is no stable ID to list in Version.Details.xml and let package version propagation (PVP) override. Add a payload-free Microsoft.NET.Runtime.Emscripten.Internal package to serve as that stable ID. All emsdk packages share $(PackageVersion) via Microsoft.NET.Runtime.Emscripten.Common.props, so it faithfully stands in for all of them, and PVP can now flow the locally built version into runtime. Do the same in src/sdk, which had the same problem in workloads.csproj. Its two Emscripten Cache.win-x64 entries in Version.Details.xml were unreferenced, so drop them in favour of the new package. The new package is RID-agnostic, so Arcade's EnableDefaultRidSpecificArtifacts handling publishes it externally only from the RID-agnostic vertical and marks it Vertical elsewhere, which keeps it consumable in-vertical without duplicate assets. Co-authored-by: Copilot <[email protected]> Copilot-Session: 9ffabacd-e239-4bbc-9f9f-8ff2cc616bae
Resolved conflicts in the Maestro-generated Version.Details.props files by taking the newly flowed versions and re-applying the Microsoft.NET.Runtime.Emscripten.Internal entries on top. Co-authored-by: Copilot <[email protected]> Copilot-Session: 9ffabacd-e239-4bbc-9f9f-8ff2cc616bae
SanityCheckUnixFilePermissionsFile ran for every pkgproj on non-Windows, but the data/UnixFilePermissions.xml it validates is only produced by GenerateUnixPermissionsFile, which just the four payload-carrying packages pull in. Microsoft.NET.Runtime.Emscripten.Internal ships no tools, so the check failed the emsdk build in the Browser_Shortstack_wasm vertical. Condition the check on ArtifactsDirToPackage, which is set by exactly those four packages, so coverage is unchanged for everything that carries executables. Co-authored-by: Copilot <[email protected]> Copilot-Session: 9ffabacd-e239-4bbc-9f9f-8ff2cc616bae
Arcade's DefaultVersions.props imports eng/Versions.props well before it imports DotNetPackageVersionPropsPath, so a property derived in Versions.props captures the Version.Details.props value and never sees the propagated one. The browser vertical showed this directly: package version propagation set MicrosoftNETRuntimeEmscriptenInternalPackageVersion to 11.0.0-ci, but EmsdkPackageVersion still held 11.0.0-rc.1.26379.102 and runtime restored a previously published emsdk from the feed. Move the definition to eng/AcquireEmscriptenSdk.targets, which is evaluated after the propagation props. Its only consumers are PackageReference items, which are evaluated after all properties, so they still observe it. Co-authored-by: Copilot <[email protected]> Copilot-Session: 9ffabacd-e239-4bbc-9f9f-8ff2cc616bae
mmitche
approved these changes
Aug 10, 2026
mmitche
left a comment
mmitche
left a comment
Member
There was a problem hiding this comment.
What kind of effect does this have on shortstack build times?
Member
Author
|
@mmitche it only affects the browser-wasm job and it goes from ~40mins to ~70mins, well below the long-pole jobs |
akoeplinger
enabled auto-merge (squash)
August 11, 2026 14:22
ViktorHofer
approved these changes
Aug 11, 2026
This was referenced Aug 13, 2026
This was referenced Aug 20, 2026
This was referenced Aug 28, 2026
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.
The browser (WebAssembly) runtime build needs the Emscripten toolchain provided by
emsdk. This adds a browser-gatedRepositoryReferencefromruntimetoemsdkso that emsdk source changes are consumed by the runtime browser build in the same vertical.emsdkis a host build tool, soemsdk.projoverrides the targetOS/architecture/RIDto the host values, while the vertical keeps flowingTargetOS=browser(so emsdk stays a ShortStack build and its assets keepVerticalvisibility, i.e. they aren't published from the browser-wasm job).We add a new marker package to flow the version from emsdk to runtime.