Allow loading MSBuild into separate AssemblyLoadContext
twsouthwick opened this issue · 2 comments
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:
- 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
- Add an overload to
RegisterMSBuild{xxx}(...)
that takes anAssemblyLoadContext
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.
MSBuild itself has some assumptions about running in the default ALC. I don't think we had a bug for that so I filed dotnet/msbuild#6794.
Until that is fixed, I'm not sure if there's value in changing Locator's behavior, but as soon as it's possible/supported to load MSBuild in an ALC Locator should definitely support/encourage it as well.