[msbuild] Fix using .NET Core assemblies for MSBuild tasks within VS#25850
[msbuild] Fix using .NET Core assemblies for MSBuild tasks within VS#25850rolfbjarne wants to merge 1 commit into
Conversation
The standard MSBuild task overrides (MakeDir, Copy, Delete, etc.) in Xamarin.Shared.targets exist to support remoting from VS/Windows to a Mac. Previously, they shared the same Runtime and AssemblyFile as our custom tasks (via _TaskRuntime/_TaskAssemblyName), which meant when _TaskRuntime='NET', these standard task overrides would also try to use the .NET task host. This caused MSB4216 errors in Visual Studio because VS couldn't reliably create the .NET task host process (especially on Windows ARM64). The fix introduces separate properties (_RemotingTaskRuntime and _RemotingTaskAssemblyName) for these standard task overrides, which always use the netstandard2.0 assembly with CurrentRuntime. This lets them run in-process without requiring the task host, while our custom tasks (Xamarin.MacDev.Tasks.*) continue to use the .NET Core assemblies via the task host as intended. With this fix, the _UseDesktopTaskAssemblies workaround that forced ALL tasks to use netstandard2.0 when building inside Visual Studio is no longer needed and has been removed. The property is still honored as an escape hatch if explicitly set. Fixes #25418 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
🔥 [PR Build #639c0e0] Build failed (Detect API changes) 🔥Build failed for the job 'Detect API changes' (with job status 'Failed') Pipeline on Agent |
|
🔥 Unable to find the contents for the comment: D:\a\1\s\change-detection\results\gh-comment.md does not exist :fire Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
🔥 [PR Build #639c0e0] Build failed (Build macOS tests) 🔥Build failed for the job 'Build macOS tests' (with job status 'Failed') Pipeline on Agent |
✅ [PR Build #639c0e0] Build passed (Build packages) ✅Pipeline on Agent |
🔥 [CI Build #639c0e0] Test results 🔥Test results❌ Tests failed on VSTS: test results 5 tests crashed, 1 tests failed, 173 tests passed. Failures❌ windows tests1 tests failed, 2 tests passed.Failed tests
Html Report (VSDrops) Download ❌ Tests on macOS Monterey (12) tests🔥 Failed catastrophically on VSTS: test results - mac_monterey (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Ventura (13) tests🔥 Failed catastrophically on VSTS: test results - mac_ventura (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Sonoma (14) tests🔥 Failed catastrophically on VSTS: test results - mac_sonoma (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Sequoia (15) tests🔥 Failed catastrophically on VSTS: test results - mac_sequoia (no summary found). Html Report (VSDrops) Download ❌ Tests on macOS Tahoe (26) tests🔥 Failed catastrophically on VSTS: test results - mac_tahoe (no summary found). Html Report (VSDrops) Download Successes✅ assembly-processing: All 1 tests passed. Html Report (VSDrops) Download macOS testsLinux Build VerificationPipeline on Agent |
2 participants
The standard MSBuild task overrides (MakeDir, Copy, Delete, etc.) in Xamarin.Shared.targets exist to support remoting from VS/Windows to a Mac. Previously, they shared the same Runtime and AssemblyFile as our custom tasks (via _TaskRuntime/_TaskAssemblyName), which meant when _TaskRuntime='NET', these standard task overrides would also try to use the .NET task host. This caused MSB4216 errors in Visual Studio because VS couldn't reliably create the .NET task host process (especially on Windows ARM64).
The fix introduces separate properties (_RemotingTaskRuntime and _RemotingTaskAssemblyName) for these standard task overrides, which always use the netstandard2.0 assembly with CurrentRuntime. This lets them run in-process without requiring the task host, while our custom tasks (Xamarin.MacDev.Tasks.*) continue to use the .NET Core assemblies via the task host as intended.
With this fix, the _UseDesktopTaskAssemblies workaround that forced ALL tasks to use netstandard2.0 when building inside Visual Studio is no longer needed and has been removed. The property is still honored as an escape hatch if explicitly set.
Fixes #25418