Build: perf_bench XAML projects fail on ARM64 — XamlCompiler.exe exits with code 1 (MSB3073)

[azchohfi]

Summary

dotnet build Reactor.slnx -c Release fails on an ARM64 host (the default arch on an ARM64 dev box) for the XAML-bearing tests/perf_bench/** harness projects. The WinUI XAML markup compiler — the net472 XamlCompiler.exe shipped in Microsoft.WindowsAppSDK.WinUI 2.0.12 — exits with code 1 and MSBuild surfaces only MSB3073, with no further diagnostic in the log:

C:\Users\<user>\.nuget\packages\microsoft.windowsappsdk.winui\2.0.12\buildTransitive\Microsoft.UI.Xaml.Markup.Compiler.interop.targets(764,9):
error MSB3073: The command ""...\tools\net6.0\..\net472\XamlCompiler.exe"
"obj\ARM64\Release\net10.0-windows10.0.22621.0\\input.json"
"obj\ARM64\Release\net10.0-windows10.0.22621.0\\output.json"" exited with code 1.

Repro

dotnet build tests\perf_bench\PerfBench.InteractivePool\InteractivePool.Bound\InteractivePool.Bound.csproj -c Release -p:Platform=ARM64

Fails reliably. Also reproduces via the full-solution build (dotnet build Reactor.slnx -c Release, which defaults to ARM64 on an ARM64 host).

Affected projects

A full-solution Release build surfaced four:

• PerfBench.InteractivePool\InteractivePool.Bound
• PerfBench.InteractivePool\InteractivePool.Direct
• PerfBench.StructuralSharing\StructuralSharing.Bound
• PerfBench.StructuralSharing\StructuralSharing.Direct

These four are just the ones that surfaced before the parallel build cascaded. Every PerfBench.*\*.Bound and *.Direct project ships an App.xaml (20 such projects), so the root cause very likely affects the whole XAML-bearing perf_bench family on ARM64, not only these four.

Pre-existing — not caused by any in-flight change

Confirmed by stashing all working-tree changes and rebuilding one project on the pristine tree: identical XamlCompiler.exe exited with code 1 (MSB3073). This is independent of the /perf work in #677.

Not affected

• The /perf gate. It only builds StressPerf.ReactorOptimized and StressPerf.Direct, which have no XAML markup; both build cleanly self-contained on ARM64 (and CI is x64).
• The rest of the solution (src/Reactor, samples, selftest/E2E hosts, StressPerf.*) compiled green in the same run.
• CI on windows-latest (x64) — main is green there. This appears to be ARM64-host specific.

Suspected cause / investigation directions

• XamlCompiler.exe resolves to the net472 build (...\tools\net6.0\..\net472\XamlCompiler.exe), a .NET Framework tool. Under ARM64 it runs via emulation; the failure is plausibly an emulation / arch-resolution issue in the markup compiler. Worth confirming whether a net6.0 variant exists and why the net472 path is selected.
• Capture the compiler's real diagnostics: run XamlCompiler.exe input.json output.json directly against a failing project's obj\ARM64\... and inspect stdout/stderr + output.json.
• Check whether forcing -p:Platform=x64 (or an x64 XamlCompiler) avoids it, to localize the issue to the ARM64 toolchain.
• Check for a newer Microsoft.WindowsAppSDK that ships an ARM64-native or net6.0 markup compiler.

Environment

• Host: Windows on ARM64
• .NET SDK 10.0.301
• Microsoft.WindowsAppSDK.WinUI 2.0.12
• Repo: microsoft/microsoft-ui-reactor @ main (discovered while validating CI: make /perf work on pre-gate PRs (self-contained C# overlay) + fix Rust column (#674) #677)

Filed as a follow-up from #677; out of scope for that PR (which is /perf CI-script only).

[azchohfi]

Root cause: Windows MAX_PATH (260), surfaced on long checkout paths

The Windows App SDK's XAML markup compiler (XamlCompiler.exe) and resource indexer (MakePri.exe) are 32-bit tools with no long-path support. When the repo is cloned to a long path — a deeply nested folder, or a OneDrive-synced user-profile path — a project's generated obj/bin output paths exceed the 260-character limit and these tools fail:

• XAML markup compile → MSB3073 (XamlCompiler.exe exits with code 1)
• Resource indexer → PRI210 / APPX0002 (e.g. moving the final resources.pri into bin)

It is most visible on ARM64 dev boxes because those tools run under x86 emulation there, but the real discriminator is the clone path length, not the architecture — it reproduces on a pristine main. x64 CI and the /perf gate are unaffected because they build from short paths. So this is a dev-box ergonomics issue, not a product/CI defect.

Resolution (#684): clone to a short path

Rather than add build machinery, the short-path recommendation is now documented in the README Quick start and CONTRIBUTING Prerequisites:

Clone into a short root directory such as C:\src\ (e.g. C:\src\microsoft-ui-reactor) rather than a deeply nested or OneDrive-synced folder.

Relocating an affected checkout to a short root makes the same toolchain build successfully. (git config --global core.longpaths true lets Git check out long paths, but the Windows App SDK build tools still require the short checkout path.)