Skip to content

Add runtime mismatch validation when Runtime is explicitly specified in custom task#12642

Merged
YuliiaKovalova merged 10 commits intovs18.0from
dev/ykovalova/detect_runtime_missmatch
Oct 21, 2025
Merged

Add runtime mismatch validation when Runtime is explicitly specified in custom task#12642
YuliiaKovalova merged 10 commits intovs18.0from
dev/ykovalova/detect_runtime_missmatch

Conversation

@YuliiaKovalova
Copy link
Member

@YuliiaKovalova YuliiaKovalova commented Oct 14, 2025

Context

Currently, in order to have Runtime="Net" executed out-of-proc, you must explicitly specify TaskFactory="TaskHostFactory" in the UsingTask element.

Changes Made

Added runtime mismatch validation when Runtime is explicitly specified to omit TaskFactory specification in UsingTask.

Regression

No

Risks

Low — validation logic only affects cases where Runtime is explicitly set.

Testing

Added a dedicated test.

Copilot AI review requested due to automatic review settings October 14, 2025 16:51
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

Adds validation to ensure custom tasks execute out-of-process when a Runtime parameter (e.g., "Net") is explicitly specified but doesn't match the current process runtime. Previously, this required explicit TaskFactory="TaskHostFactory" in the UsingTask declaration.

Key Changes

  • Modified type loading logic to check if task host parameters match the current process
  • Introduced isTaskHostParamsMatchCurrentProc parameter to control metadata load context usage
  • Added end-to-end test validating out-of-process execution with explicit Runtime specification

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
src/Shared/TypeLoader.cs Added isTaskHostParamsMatchCurrentProc parameter throughout type loading chain to enable runtime mismatch detection
src/Build/Instance/TaskFactories/AssemblyTaskFactory.cs Initialized runtime mismatch detection by comparing task host parameters with current process
src/Build.UnitTests/TestAssets/ExampleNetTask/TestNetTaskWithImplicitParams/global.json Added SDK configuration for test asset to prevent SDK path resolution issues
src/Build.UnitTests/TestAssets/ExampleNetTask/TestNetTaskWithImplicitParams/TestNetTaskWithImplicitParams.csproj Created test project with Runtime="NET" to validate out-of-process execution
src/Build.UnitTests/NetTaskHost_E2E_Tests.cs Added test verifying task executes out-of-process when Runtime is specified without TaskHostFactory
src/Build.UnitTests/Microsoft.Build.Engine.UnitTests.csproj Added reference to new test asset's global.json file

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@YuliiaKovalova YuliiaKovalova changed the base branch from main to vs18.0 October 16, 2025 14:19
@YuliiaKovalova YuliiaKovalova enabled auto-merge (squash) October 21, 2025 08:41
@YuliiaKovalova YuliiaKovalova merged commit 995a3dc into vs18.0 Oct 21, 2025
10 checks passed
@YuliiaKovalova YuliiaKovalova deleted the dev/ykovalova/detect_runtime_missmatch branch October 21, 2025 09:49
YuliiaKovalova added a commit that referenced this pull request Dec 10, 2025
…ks (CLR35 and CLR2) (#12823)

### Context

The recent change #12642 helped to
uncover a long-term bug when a custom task was eventually executed
out-of-proc, but due to lack of architecture/runtime match check BEFORE
the TypeLoad, it was lazily loaded in-proc and pushed out-of-proc later.

https://github.com/dotnet/msbuild/blob/ee6457a6b06e66a5e4037549c84d8282ecd0df92/src/Build/Instance/TaskFactories/AssemblyTaskFactory.cs#L335
look at  `!TaskHostParametersMatchCurrentProcess`

### Changes Made
- Fixed assembly enumeration: Previously only `.dll` files were added to
MetadataLoadContext's resolver. Now `.exe` files are also included,
since executables can be valid managed assemblies and dependencies.

- Added legacy .NET Framework support (.NET Framework only): Added
assembly discovery for v2.0 and v3.5 framework directories to support
tasks that depend on legacy Microsoft.Build.Utilities.dll (as opposed to
the modern Microsoft.Build.Utilities.Core.dll).

### Test 
Locally tested with custom tasks using both modern and legacy MSBuild
assemblies + current tests confirm there are no regression.

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants