[release/10.0.1xx] [dotnet] Use desktop MSBuild task assemblies in VS for all platforms - #25718
Conversation
… not just iOS When building inside Visual Studio on Windows, our MSBuild tasks (including the built-in tasks we override, such as MakeDir) were registered with Runtime="NET" and the net assemblies for every platform except iOS. That requires MSBuild to spin up a .NET task host, which doesn't work reliably - in particular it fails on Windows ARM64 with: error MSB4216: Could not run the "MakeDir" task because MSBuild could not create or connect to a task host with runtime "NET" and architecture "*". #25417 worked around this for iOS by setting _UseDesktopTaskAssemblies=true (which selects the netstandard2.0 task assemblies and Runtime=CurrentRuntime, so the tasks run in-process) inside VS, but it only added the property to Microsoft.iOS.Sdk.props. MacCatalyst, macOS and tvOS were left out, so a net*-maccatalyst project still failed to build in VS on Windows ARM64. Move the property into the shared Xamarin.Shared.Sdk.props (imported by all four platform SDKs) so the workaround applies everywhere. The iOS Sdk.props keeps setting it earlier because it also drives CoreiOSSdkDirectory, and the '== ' guard makes the shared copy idempotent. Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/3013050 Ref: #25418 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
This PR ensures MSBuild tasks run in-process inside Visual Studio by forcing use of the desktop (netstandard2.0) task assemblies across all Apple platform SDKs, avoiding reliance on the separate .NET task host that fails on Windows ARM64 (MSB4216).
Changes:
- Set
_UseDesktopTaskAssemblies=trueinXamarin.Shared.Sdk.propswhenBuildingInsideVisualStudioistrue. - Guard the shared setting with
'$(_UseDesktopTaskAssemblies)' == ''so the iOS-specific earlier setting remains authoritative (and continues to driveCoreiOSSdkDirectory).
✅ [PR Build #8d262ac] Build passed (Detect API changes) ✅Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
✅ [PR Build #8d262ac] Build passed (Build packages) ✅Pipeline on Agent |
✅ API diff for current PR / commitNET (empty diffs)✅ API diff vs stableNET (empty diffs)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
✅ [PR Build #8d262ac] Build passed (Build macOS tests) ✅Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
🚀 [CI Build #8d262ac] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 175 tests passed 🎉 Tests counts✅ cecil: All 1 tests passed. Html Report (VSDrops) Download macOS tests✅ Tests on macOS Monterey (12): All 5 tests passed. Html Report (VSDrops) Download Linux Build VerificationPipeline on Agent |
Description
Building a MacCatalyst app inside Visual Studio on Windows ARM64 fails with:
Root cause
Inside Visual Studio, our MSBuild tasks should run in-process using the
netstandard2.0assemblies. This is controlled by the_UseDesktopTaskAssembliesproperty. When it is not set, the tasks instead use the.NETassemblies, which need a separate .NET task host. That task host does not work reliably from Visual Studio, and fails on Windows ARM64.#25417 set
_UseDesktopTaskAssembliesfor Visual Studio builds, but only in the iOS SDK. MacCatalyst, macOS and tvOS were missed, so they still try to use the .NET task host and break.Fix
Set
_UseDesktopTaskAssembliesin the sharedXamarin.Shared.Sdk.props, which is imported by all four platforms, so the workaround applies everywhere. The iOS SDK keeps setting it earlier (it also needs it forCoreiOSSdkDirectory); the== ''guard makes the shared copy a no-op for iOS.Ref: #25418
Co-authored-by: Milos Kotlar kotlarmilos@gmail.com
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com
Backport of #25662.