Skip to content

Add escape hatch for not sharing assemblies from tools directory#13305

Merged
rainersigwald merged 1 commit intodotnet:mainfrom
AR-May:fix-loading-issue-when-using-msbuild-api
Mar 5, 2026
Merged

Add escape hatch for not sharing assemblies from tools directory#13305
rainersigwald merged 1 commit intodotnet:mainfrom
AR-May:fix-loading-issue-when-using-msbuild-api

Conversation

@AR-May
Copy link
Copy Markdown
Member

@AR-May AR-May commented Feb 27, 2026

Fixes #13286

Context

When MSBuild resolves dependencies for a task, if it cannot find the dependent assembly in the task assembly's directory, it tries finding it in MSBuild's tools directory. In that case, the dependency is loaded to AssemblyLoadContext.Default instead of the task's own ALC, in order to share it across tasks and avoid loading it multiple times.

However, loading it to the default ALC does not reliably work if MSBuild is running on an arbitrary host app (such as by being loaded by MSBuildLocator), because it will cause failures if the host app has itself a dependency on an older assembly version than the task's dependency. This is what caused the linked issue.

Changes Made

Added escape hatch that customers can set up to work around this problem.

Testing

manual, tested on the provided repro project

@AR-May AR-May force-pushed the fix-loading-issue-when-using-msbuild-api branch from 4f68098 to 57a258e Compare February 27, 2026 14:46
@AR-May AR-May marked this pull request as ready for review February 27, 2026 15:22
Copilot AI review requested due to automatic review settings February 27, 2026 15:22
@AR-May AR-May requested a review from rainersigwald February 27, 2026 15:23
Copy link
Copy Markdown
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

This PR introduces an escape hatch to address assembly loading issues when MSBuild is hosted by applications (like via MSBuildLocator) that may have conflicting dependency versions. The change allows users to opt-in to loading MSBuild tools directory assemblies into isolated AssemblyLoadContexts instead of the default shared context.

Changes:

  • Added a new environment variable-based escape hatch (MSBUILDUSECUSTOMLOADCONTEXTFORDEPENDENCIESINTOOLSDIRECTORY) to control assembly loading behavior
  • Modified assembly loading logic to conditionally use custom or default AssemblyLoadContext based on the escape hatch setting

Reviewed changes

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

File Description
src/Shared/MSBuildLoadContext.cs Updated assembly loading logic to check the escape hatch and load into appropriate context
src/Framework/Traits.cs Added new escape hatch property for controlling dependency loading behavior

Copy link
Copy Markdown
Member

@rainersigwald rainersigwald left a comment

Choose a reason for hiding this comment

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

lgtm as long as @AndyGerlicher @dfederm are ok with it.

@rainersigwald
Copy link
Copy Markdown
Member

Got IM approval, let's try it.

@rainersigwald rainersigwald merged commit 0b2773e into dotnet:main Mar 5, 2026
14 checks passed
@AR-May AR-May self-assigned this Mar 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MSBuildLoadContext.Load() causes FileLoadException for self-contained .NET apps loading MSBuild in-proc

3 participants