Make arm64 a first-class build host (auto-detect host arch)#11250
Open
dennisameling wants to merge 4 commits into
microsoft:mainmicrosoft/microsoft-ui-xaml:mainfrom
dennisameling:arm64-first-class-build-hostdennisameling/microsoft-ui-xaml:arm64-first-class-build-hostCopy head branch name to clipboard
Open
Make arm64 a first-class build host (auto-detect host arch)#11250dennisameling wants to merge 4 commits intomicrosoft:mainmicrosoft/microsoft-ui-xaml:mainfrom dennisameling:arm64-first-class-build-hostdennisameling/microsoft-ui-xaml:arm64-first-class-build-hostCopy head branch name to clipboard
dennisameling wants to merge 4 commits into
microsoft:mainmicrosoft/microsoft-ui-xaml:mainfrom
dennisameling:arm64-first-class-build-hostdennisameling/microsoft-ui-xaml:arm64-first-class-build-hostCopy head branch name to clipboard
Conversation
The build scripts hardcoded amd64 for the *host* toolchain, so on a native arm64 machine everything ran x64-emulated. Detect the native host architecture and select the matching native toolchain, falling back to amd64 for any host that is neither arm64 nor amd64 (x86, or a future arch such as RISC-V). This is independent of the *target* architecture being built. Host-toolchain selection (MSBuild, VsDevCmd host, VC compilers, Windows SDK tools, PGO merge, .NET SDK): - scripts/init/SetHostArch.cmd: new shared helper that sets _HostArch to amd64|arm64. Prefers the machine-level PROCESSOR_ARCHITECTURE from the registry (authoritative even from an emulated shell), then PROCESSOR_ARCHITEW6432, then PROCESSOR_ARCHITECTURE. - init.cmd: use _HostArch for the MSBuild Bin paths and all three DevCmd -host_arch calls (was amd64). - scripts/init/Initialize-InstallMSBuild.ps1, build/DownloadDotNetCoreSdk.ps1: detect host arch via RuntimeInformation.OSArchitecture. The in-repo .NET SDK is now installed native (arm64) on an arm64 host. - scripts/init/SetMSBuildVars.cmd, src/XamlCompiler/runtests.cmd: use the shared helper. PreferredToolArchitecture is host-aware in eng/sdkconfig.props, controls/environment.props and controls/dev/dll/Microsoft.UI.Xaml.Common.props (was hardcoded x64). This one property drives both the VC host compilers (cl.exe/link.exe -> bin\Host<arch>) and the Windows SDK tools (midlrt/mc/rc -> WindowsSdkToolLocation). arm64 on an arm64 host, else x64. perf/pgo/Microsoft.WinUI.PGO.props: select pgomgr.exe (PGO profile merge) by host arch. pgomgr /merge is target-agnostic (the repo already used the x64 pgomgr to merge ARM64 target data), so use the native arm64 pgomgr on an arm64 host; non-arm64 hosts keep the previous behavior exactly. CI: .github/workflows/pr-build.yml gains an os matrix axis crossing windows-2022 (x64) and windows-11-arm, so every flavor builds on both hosts for toolchain parity. Artifact names are namespaced by host. Validated on a Windows 11 arm64 machine: native arm64 MSBuild/cl/link/midlrt build the dxaml core product and package the arm64 native runtime. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The windows-11-arm GitHub runner image ships most VS components but lacks VC.Runtimes.x86.x64.Spectre (and the version-pinned 14.44 Spectre variants), so all six flavors fail with MSB8040 - even arm64 targets, because the codegen tools (gencompheadersandidl, genmrtheadersandidl, manifest) compile as x86/x64. Add a windows-11-arm-only step that applies the repo's .vsconfig via the VS Installer before building, matching the toolchain the build expects. windows-2022 already includes these components. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
On an arm64 host, MSBuild (and the AnyCPU XamlCompiler.exe it launches) runs arm64, so the XamlCompiler loads GenXbf.dll from the arm64 folder regardless of the product target arch. BuildGenXbfForMSBuild only ever built x64 + the host SDK-tools arch (x86 on arm64), so x86/x64-target builds on an arm64 host failed with 'Cannot resolve GenXbf.dll under ...\GenXbf\arm64' (WMC0621). arm64-target builds happened to work because they compile GenXbf as arm64 anyway. Add an arm64 GenXbf reference gated on an arm64 host, mirroring the existing always-x64 reference. Verified locally: an x64-target build on an arm64 host now produces BuildOutput\bin\GenXbf\arm64\genxbf.dll. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Building the arm64 GenXbf.dll (added in the previous commit) links against the arm64 Windows SDK (e.g. kernel32.lib from Microsoft.Windows.SDK.cpp.arm64). PostInit only restored packages.arm64.config for arm64/arm64ec product targets, so x86/x64-target builds on an arm64 host failed the GenXbf link with LNK1181 'cannot open input file kernel32.lib'. Restore packages.arm64.config whenever the build host is arm64, regardless of the product target. Verified locally: an x86-target build on an arm64 host now builds the arm64 GenXbf.dll cleanly (0 errors) with the arm64 SDK present. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.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
1 participant
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.
Fixes
Fixes #11249
PR Type
Description
The build scripts hardcoded
amd64for the host toolchain, so on a native arm64 machine everything ran x64-emulated. This auto-detects the native host architecture and selects the matching native toolchain, falling back toamd64for any host that is neither arm64 nor amd64 (x86, or a future arch such as RISC-V). Independent of the target architecture being built.While arm64 devices can run x64 tools like cl.exe and MSBuild.exe under emulation, Visual Studio 2022 and later offers native arm64 versions of these build tools as well, which significantly speeds up the build process.
Current Behavior
The
.\Build.cmdscript always invokes amd64/x64 host tools, even on arm64 devicesNew Behavior
The
.\Build.cmdscript auto-detects the host architecture and uses native arm64 build tools on arm64 devices, such as the Surface Pro X.Customer Impact
Just build-related changes for users who want to contribute to this repository.
Regression Potential
How Has This Been Tested?
Also, here's a successful CI build on both an x64 and arm64 host: https://github.com/dennisameling/microsoft-ui-xaml/actions/runs/29587060879
Screenshots (if appropriate)