Summary
On the osx.15.arm64.open Helix queue, the SDK payload installed under %HELIX_CORRELATION_PAYLOAD%\d\ ships an arm64 SDK (sdk\11.0.100-ci, runtime Microsoft.NETCore.App\11.0.0-preview.x arm64) but also includes an x86_64-only copy of Microsoft.NETCore.App\10.0.0. Any tool that targets net10.0 and is launched via dotnet exec against this payload fails to load with:
Failed to load /private/tmp/helix/working/<…>/p/d/shared/Microsoft.NETCore.App/10.0.0/libhostpolicy.dylib, error:
dlopen(…/libhostpolicy.dylib, 0x0001): tried: '…/libhostpolicy.dylib' (mach-o file, but is an incompatible architecture
(have 'x86_64', need 'arm64e' or 'arm64'))
An error occurred while loading required library libhostpolicy.dylib from
[…/shared/Microsoft.NETCore.App/10.0.0]
<RollForward>Major</RollForward> does not help — the host successfully resolves 10.0.0 (it exists on disk), then fails at dlopen time. Only --roll-forward LatestMajor combined with DOTNET_ROLL_FORWARD_TO_PRERELEASE=1 would bypass it (by jumping to the prerelease 11.x), which masks the real customer-facing minimum-runtime scenario for tests.
Repro
- Submit a Helix work item targeting
osx.15.arm64.open from the dotnet/sdk pipeline.
- From the work item, run any
net10.0 tool DLL: dotnet exec /tmp/.../tools/Microsoft.DotNet.ApiCompat.Tool.dll --help (or any other net10-targeted tool such as apicompat, apidiff, genapi).
- Observe the dlopen architecture mismatch.
Impact
PR #54205 introduced integration tests for the ApiCompat / GenAPI / ApiDiff CLI tools. They cannot run on macOS arm64 today — they are skipped via [PlatformSpecificFact(skipPlatforms: TestPlatforms.OSX, skipArchitecture: Architecture.Arm64)] referencing this issue. Once the payload is fixed (arm64 runtime for Microsoft.NETCore.App\10.0.0, or a different layout that doesn't carry an x86_64-only runtime onto arm64 hosts), the skip can be removed.
Expected
The Helix payload for osx.*.arm64.* queues should include only arm64-compatible shared frameworks (or none, leaving roll-forward to handle the gap to the SDK's bundled runtime).
Summary
On the
osx.15.arm64.openHelix queue, the SDK payload installed under%HELIX_CORRELATION_PAYLOAD%\d\ships an arm64 SDK (sdk\11.0.100-ci, runtimeMicrosoft.NETCore.App\11.0.0-preview.xarm64) but also includes an x86_64-only copy ofMicrosoft.NETCore.App\10.0.0. Any tool that targetsnet10.0and is launched viadotnet execagainst this payload fails to load with:<RollForward>Major</RollForward>does not help — the host successfully resolves10.0.0(it exists on disk), then fails at dlopen time. Only--roll-forward LatestMajorcombined withDOTNET_ROLL_FORWARD_TO_PRERELEASE=1would bypass it (by jumping to the prerelease 11.x), which masks the real customer-facing minimum-runtime scenario for tests.Repro
osx.15.arm64.openfrom the dotnet/sdk pipeline.net10.0tool DLL:dotnet exec /tmp/.../tools/Microsoft.DotNet.ApiCompat.Tool.dll --help(or any other net10-targeted tool such asapicompat,apidiff,genapi).Impact
PR #54205 introduced integration tests for the ApiCompat / GenAPI / ApiDiff CLI tools. They cannot run on macOS arm64 today — they are skipped via
[PlatformSpecificFact(skipPlatforms: TestPlatforms.OSX, skipArchitecture: Architecture.Arm64)]referencing this issue. Once the payload is fixed (arm64 runtime forMicrosoft.NETCore.App\10.0.0, or a different layout that doesn't carry an x86_64-only runtime onto arm64 hosts), the skip can be removed.Expected
The Helix payload for
osx.*.arm64.*queues should include only arm64-compatible shared frameworks (or none, leaving roll-forward to handle the gap to the SDK's bundled runtime).