Allow loading MSBuild into separate AssemblyLoadContext

Open
#134 2 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
csharp
Domain
build-system, tooling

Research direction

Start by tracing the RegisterMSBuild{xxx}(...) APIs and their use of AssemblyLoadContext.Default. Compare contextual reflection with an overload accepting an AssemblyLoadContext, then investigate how loaded-state tracking, unloading, and process-wide MSBuild environment variables affect multiple instances. Done requires a decided design that supports separate lifetime management without unresolved cross-instance conflicts.

Written by the indexing model from the issue text.

Description

Currently, the MSBuild assemblies are loaded into the default AssemblyLoadContext. However, I'm interested in being able to load it into a seprate one so I can manage its lifetime separately from the rest of the app.

There are two ways I see this can be added:

  1. Replace the call to AssemblyLoadContext.Default to .CurrentContextualReflectionContext (which will require adding a .NET Core 3.1+ target)
#if NETCOREAPP2_1
            AssemblyLoadContext.Default.Resolving += s_registeredHandler;
#else
            var alc = AssemblyLoadContext.CurrentContextualReflectionContext ?? AssemblyLoadContext.Default;
            alc.Resolving += s_registeredHandler;
#endif
  1. Add an overload to RegisterMSBuild{xxx}(...) that takes an AssemblyLoadContext

Problems with this:

  • Either way, it will only allow loading it into a single AssemblyLoadContext and currently wouldn't understand an assembly load context being unloaded
  • Even if it were allowed in multiple assembly load contexts, .NET SDK msbuild instances register environment variables that will continue to be process wide and would therefor potentially cause conflicts if multiple msbuild instances are loaded at once

The first problem is surmountable by changing how it's tracked that MSBuild is loaded. The second issue is something I don't have an answer for.

Dominant language
C#
Stars
262
Forks
91
Avg merge
11d 22h
Merged PRs (30d)
3

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/MSBuildLocator

All issues in microsoft/MSBuildLocator

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.