Remove assumption that MSBuild controls AssemblyLoadContext.Default

[rainersigwald]

MSBuild has several explicit references to AssemblyLoadContext.Default. That prevents an application from using the MSBuild API in a disposable (or otherwise managed) context.

msbuild/src/Shared/TaskEngineAssemblyResolver.cs

Line 126 in 414393f

return AssemblyLoadContext.Default.LoadFromAssemblyPath(_taskAssemblyFile);

msbuild/src/Shared/MSBuildLoadContext.cs

Lines 82 to 85 in 414393f

	if (FileSystems.Default.FileExists(assemblyNameInExecutableDirectory))
	{
	return AssemblyLoadContext.Default.LoadFromAssemblyPath(assemblyNameInExecutableDirectory);
	}

This one is potentially OK since it's only to support an escape-hatch feature, but we can also consider removing it:

msbuild/src/Shared/CoreCLRAssemblyLoader.cs

Lines 65 to 83 in 414393f

	private Assembly LoadUsingLegacyDefaultContext(string fullPath)
	{
	lock (_guard)
	{
	if (!_resolvingHandlerHookedUp)
	{
	AssemblyLoadContext.Default.Resolving += TryResolveAssembly;
	_resolvingHandlerHookedUp = true;
	}
	Assembly assembly;
	if (_pathsToAssemblies.TryGetValue(fullPath, out assembly))
	{
	return assembly;
	}
	return LoadAndCache(AssemblyLoadContext.Default, fullPath);
	}
	}

[jzabroski]

@rainersigwald What would you like to see as the solution here? Maybe I can contribute a PR?

[RikkiGibson]

It would be nice to be able to load MSBuild in a non-default ALC. This might allow the editor to do design-time builds without needing to start a subprocess for many .NET Core projects. I think there would be other roadblocks, but this is one of them.

[jzabroski]

Yes, and with the Visual Studio IDE rapidly pivoting towards a multi-agent orchestration layer, the ability to do design-time builds seems advantageous. However, why wouldn't you want a sub-process in such a world? Innocent question - you may be a few steps ahead of me in thinking this through. I only am thinking of it as I am building Visual Studio plug-ins to orchestrate dozens of agents. I think it's less about starting a sub-process and more having sub-process pooling, where you can reclaim the load context by disposing it and acquiring a new one. Processes are elegant in that they allow a hard bound on memory allocation.

[RikkiGibson]

What I have in mind is just cold start performance in the Roslyn LS. Time from vscode launch to getting diagnostics, or time from asking copilot to start doing a task, to it getting the first answer it needs from the LS in order to proceed.

Separately we are working on getting the LS into a loaded state that can provide meaningful answers more quickly, without needing to first do a DTB, by using data that a previous build wrote to disk.

Using a subprocess that is longer lived or has a broader lifetime (e.g. a general purpose msbuild server process, that we could start-if-needed and send our requests to) could also get us some wins, as an alternative to using ALCs. Starting .NET processes, especially on windows, and especially involving more complex libraries, plugins, lots of frequently loaded resources that get cached, etc. have significant cold start penalties before we can get into a state where we're getting real work done quickly.

[jzabroski]

I actually think you want both sub-process with broader lifetime and non-default ALC. I've thought about this a lot in the past couple of months. One example is Uno Platform Studio Hot Design™ being able to be browsed by agents and facilitating human-machine co-design.

Funny how the initial reason I wanted to help with this is very different from my motivations today. In 2021 I just wanted turtles all the way down task and sub-task management for a custom MSBuild TaskRunner Task that loads its own tasks independent of MSBuild, similar to calling Cake from MSBuild. In a way that is still similar in spirit to agents and sub-agents, but vastly different use cases.