Add implicit architecture/runtime detection for custom tasks#12630
Merged
YuliiaKovalova merged 33 commits intomainfrom Nov 27, 2025
Merged
Add implicit architecture/runtime detection for custom tasks#12630YuliiaKovalova merged 33 commits intomainfrom
YuliiaKovalova merged 33 commits intomainfrom
Conversation
Refactor task factory parameter merging to check for task host factory conditionally.
YuliiaKovalova
changed the title
YuliiaKovalova
changed the title
YuliiaKovalova
commented
Oct 13, 2025
YuliiaKovalova
commented
Oct 13, 2025
YuliiaKovalova
commented
Oct 13, 2025
YuliiaKovalova
force-pushed
the
dev/ykovalova_respect_task_arch_runtime
branch
from
5d55c8e to
adc7541
Compare
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR implements implicit architecture/runtime detection for custom tasks in MSBuild, allowing automatic TaskHost resolution without requiring explicit Runtime/Architecture attributes in project files. When custom tasks don't match the current process requirements, MSBuild now automatically detects the task's target runtime and architecture from assembly metadata and routes execution to the appropriate out-of-process TaskHost.
Key changes include:
- Dynamic task analysis through assembly metadata inspection to determine target runtime (.NET Framework vs .NET) and architecture (x86, x64, etc.)
- Intelligent execution routing that uses in-process execution when possible and falls back to out-of-process TaskHost when needed
- Enhanced LoadedType class to carry architecture and runtime information extracted from PE headers and assembly attributes
Reviewed Changes
Copilot reviewed 20 out of 21 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Shared/TypeUtilities.cs | Simplified attribute detection methods by removing exception handling and using expression-bodied members |
| src/Shared/TypeLoader.cs | Added assembly metadata analysis for runtime/architecture detection and fallback loading logic |
| src/Shared/LoadedType.cs | Extended to store architecture/runtime information and handle MetadataLoadContext exceptions |
| src/MSBuildTaskHost/TypeLoader.cs | Updated method signature to match new parameters |
| src/MSBuild/OutOfProcTaskAppDomainWrapperBase.cs | Updated to use new TypeLoader parameter signature |
| src/Framework/MSBuildEventSource.cs | Added event logging for fallback assembly loading |
| src/Build/Instance/TaskRegistry.cs | Added logic to track when TaskHostFactory is explicitly requested |
| src/Build/Instance/TaskFactories/AssemblyTaskFactory.cs | Refactored task factory logic to use detected runtime/architecture and handle MetadataLoadContext scenarios |
| src/Build.UnitTests/TestAssets/ExampleNetTask/TestNetTaskWithImplicitParams/* | New test assets for .NET task with implicit parameters |
| src/Build.UnitTests/TestAssets/ExampleFrameworkTask/* | New test assets for .NET Framework tasks with different architectures |
| src/Build.UnitTests/NetTaskHost_E2E_Tests.cs | Added end-to-end test for implicit host parameter detection |
| src/Build.UnitTests/Microsoft.Build.Engine.UnitTests.csproj | Updated project references and warnings for new test assets |
| src/Build.UnitTests/BackEnd/TaskHostFactory_Tests.cs | Updated tests to use AssemblyFile instead of AssemblyName and improved assertions |
| src/Build.UnitTests/BackEnd/AssemblyTaskFactory_Tests.cs | Modified test conditions and assembly loading logic |
| src/Build.UnitTests/BackEnd/AssemblyTaskFactory_E2E_Tests.cs | New end-to-end tests for architecture mismatch handling |
YuliiaKovalova
force-pushed
the
dev/ykovalova_respect_task_arch_runtime
branch
from
6459b11 to
a0b3ebf
Compare
YuliiaKovalova
force-pushed
the
dev/ykovalova_respect_task_arch_runtime
branch
from
f016f6c to
3490ac9
Compare
rainersigwald
pushed a commit
that referenced
this pull request
Oct 20, 2025
…odes (#12644) ### Context When a path to dotnet.exe or MSBuild.dll contains spaces, it's incorrectly escaped and causes errors like this: Could not execute because the specified command or file was not found. * You intended to execute a .NET program, but dotnet-C:\Program does not exist. The path gets truncated at the space character, causing the process launch to fail. The important notice – it’s a critical scenario for the feature dogfooding , since dotnet.exe usually is placed in “Program Files” (path with spaces). It wasn’t caught during the development because the change required coordination with SDK and the default private SDK was in a path without spaces, unlike `C:\Program Files`. ### Changes Made Added proper escaping for the msbuild.dll path to ensure it works correctly even when the path contains spaces. ### Regression No, it’s a bug in the new feature ### Risks No risks, minimal well-boxed change ### Testing UT + manual ### Notes This logic is taken from #12630
YuliiaKovalova
force-pushed
the
dev/ykovalova_respect_task_arch_runtime
branch
from
759daa9 to
14d3483
Compare
rainersigwald
approved these changes
Nov 23, 2025
Member
rainersigwald
left a comment
rainersigwald
left a comment
There was a problem hiding this comment.
Many nits but lgtm overall.
src/Build.UnitTests/TestAssets/ExampleFrameworkTask/ExampleTaskX86/ExampleTaskX86.csproj
Outdated
Show resolved
Hide resolved
YuliiaKovalova
force-pushed
the
dev/ykovalova_respect_task_arch_runtime
branch
from
d88736e to
ecac848
Compare
This was referenced Nov 28, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #12511 and #6357
Context
MSBuild currently doesn't support implicit TaskHost resolution. When customers run custom tasks without explicit Runtime/Architecture specifications in their project files, MSBuild fails with an exception if the task's requirements don't match the current process. This forces users to manually specify Runtime and Architecture attributes, creating a poor developer experience and limiting cross-platform compatibility.
Example failure scenario:
Developer builds a project on x64 with a custom task compiled for x86
Without explicit
<UsingTask Architecture="x86">, MSBuild throws an exceptionThe build fails even though MSBuild could automatically run the task in the correct host
Changes Made
Dynamic Task Analysis: When loading custom tasks, MSBuild now inspects assembly metadata to determine:
Target runtime (e.g., .NET Framework, NET)
Target architecture (x86, x64, etc.)
Intelligent Execution Routing:
Testing
Existing tests + added coverage
for implicit architecture (x86. x64) and implicit runtime (NET)