Pair to Mac provisioning ignores global.json workloadVersion and always installs the VS-bundled iOS SDK, failing with "remote iOS SDK was not found or is corrupted"

[Kebechet]

Apple platform

iOS

Framework version

net10.0-*

Affected platform version

• Windows 11, Visual Studio Enterprise 2026 18.8.12023.21 (release channel), .NET MAUI Tools 18.7.15, messaging/IDB agents 26.2.10191
• .NET SDK 10.0.302, solution global.json pins "workloadVersion": "10.0.302.1" (resolves the ios workload to manifest 26.5.10315)
• Mac build host: Xcode 26.6

Description

When a solution pins a workload set in global.json that is newer than the iOS tooling bundled in Visual Studio, Pair to Mac can never connect successfully:

1. The local Windows build correctly uses the pinned workload set, so the project resolves to the net10.0-ios 26.5 band and needs the pack Microsoft.iOS.Sdk.net10.0_26.5 version 26.5.10315 on the Mac.
2. Pair to Mac provisioning ignores global.json entirely. It generates its rollback file from the versions bundled with the VS instance and installs microsoft.net.sdk.ios 26.2.10191 on the Mac.
3. The final server validation then checks for packs/Microsoft.iOS.Sdk.net10.0_26.5/26.5.10315/ on the Mac, does not find it, and the connection is dropped with:

The connection cannot continue because the remote iOS SDK was not found or is corrupted. If the issue persists, please try removing the `~/Library/Caches/Xamarin/XMA/SDKs/dotnet/` folder on the Mac and try again

The suggested remediation in that message cannot help: after removing the folder, provisioning reinstalls the same bundled 26.2.10191 and the validation fails again. There is also no setting or MSBuild property I could find to tell provisioning which version to install.

Evidence that the provisioned version comes from the VS bundle, not from the repo or from the locally installed manifests: C:\Program Files\dotnet\sdk-manifests\10.0.100\microsoft.net.sdk.ios\ on the Windows machine contains 26.2.10191, 26.5.10284 and 26.5.10315, yet provisioning picked 26.2.10191. Same for mono toolchain: the folder contains 10.0.101, 10.0.109, 10.0.110, and the rollback file picked 10.0.101. In both cases the chosen version is exactly the one the VS installer shipped (it also matches the messaging agents version, 26.2.10191).

Why one ends up in this situation: the Mac is on Xcode 26.6, and per https://aka.ms/xcode-requirement each workload set requires one exact Xcode version, so supporting Xcode 26.6 requires pinning 26.5.10315 (per the release notes at https://github.com/dotnet/macios/releases) before any VS release bundles it. From that moment the officially documented workload-set pinning workflow and Pair to Mac are mutually exclusive.

Expected behavior: provisioning should install the workload version that the solution's global.json resolves to (or at least offer an explicit override), and when the versions cannot match, the error should state the actual version mismatch instead of suggesting a cache wipe.

Steps to Reproduce

1. On Windows with VS 2026 18.8 (bundled iOS tooling 26.2.10191), create/open a net10.0-ios app whose global.json contains "sdk": { "version": "10.0.302", "workloadVersion": "10.0.302.1" }, and run dotnet workload install ios so the local build uses ios 26.5.10315.
2. Pair to Mac (Mac has Xcode 26.6) and let automatic provisioning finish.
3. Observe the provisioning log installing microsoft.net.sdk.ios 26.2.10191 from its rollback file, followed by the failed validation: SDK relative directory: packs\Microsoft.iOS.Sdk.net10.0_26.5\26.5.10315\ and "The connection cannot continue because the remote iOS SDK was not found or is corrupted".

Did you find any workaround?

Yes, verified working: manually seed the pinned SDK into the Pair to Mac cache on the Mac, then restore the VS-bundled set so the seeded packs end up without install records. The second step matters: workload garbage collection removes any recorded pack that the currently installed manifest does not reference, so a plain seed gets garbage-collected during the next VS provisioning. Recordless packs survive because provisioning wipes metadata/ before installing and GC only considers recorded packs.

# on the Mac, inside the Pair to Mac SDK cache
cd ~/Library/Caches/maui/PairToMac/SDKs/dotnet

# 1) seed the version the repo pins
echo '{ "microsoft.net.sdk.ios": "26.5.10315/10.0.100" }' > /tmp/rollback-pinned.json
DOTNET_ROOT="$PWD" ./dotnet workload install ios --from-rollback-file /tmp/rollback-pinned.json --source https://api.nuget.org/v3/index.json

# 2) restore the VS-bundled set (rollback JSON copied verbatim from the VS connect log)
#    and strip the install records of the seeded packs
echo '{ "microsoft.net.sdk.ios": "26.2.10191/10.0.100", "microsoft.net.workload.mono.toolchain.current": "10.0.101/10.0.100", "microsoft.net.workload.mono.toolchain.net9": "10.0.101/10.0.100", "microsoft.net.workload.emscripten.current": "10.0.101/10.0.100", "microsoft.net.workload.emscripten.net9": "10.0.101/10.0.100" }' > /tmp/rollback-vs.json
rm -rf metadata
DOTNET_ROOT="$PWD" ./dotnet workload install ios --from-rollback-file /tmp/rollback-vs.json --source https://api.nuget.org/v3/index.json

After this, both packs/Microsoft.iOS.Sdk.net10.0_26.2/26.2.10191 and packs/Microsoft.iOS.Sdk.net10.0_26.5/26.5.10315 coexist on the Mac, VS provisioning passes ("already installed" for its whole set, GC uninstalls nothing) and the connection succeeds.

Build logs

Relevant excerpt of the Pair to Mac connect log (happy to attach the full log on request):

Selected project configuration for DotNet validation: ...SatisFIT.Client.App.csproj: SatisFIT.Client.App.Debug|AnyCPU|net10.0-ios.26.5
Installing workloads using rollback file:
{
  "microsoft.net.sdk.ios": "26.2.10191/10.0.100",
  "microsoft.net.workload.mono.toolchain.current": "10.0.101/10.0.100",
  "microsoft.net.workload.mono.toolchain.net9": "10.0.101/10.0.100",
  "microsoft.net.workload.emscripten.current": "10.0.101/10.0.100",
  "microsoft.net.workload.emscripten.net9": "10.0.101/10.0.100"
}
Updating to a rollback file is not compatible with workload sets. Install and Update will now use loose manifests. To update to a specific workload version, use --version.
...
Successfully installed workload(s) ios.
...
Initializing IDB environment...
SDK relative directory: packs\Microsoft.iOS.Sdk.net10.0_26.5\26.5.10315\
...
Performing server validations against 'Samuel's Mac mini'...
The connection cannot continue because the remote iOS SDK was not found or is corrupted. If the issue persists, please try removing the `~/Library/Caches/Xamarin/XMA/SDKs/dotnet/` folder on the Mac and try again