Question: How to write an MSBuild extension that is extensible

Moved from https://github.com/dotnet/sdk/issues/898 on behalf of @AArnott

I’m working to port my CodeGeneration.Roslyn MSBuild extension to .netstandard so that it works under dotnet build. The design is that folks can build on my SDK NuGet package to write their Roslyn-based code generator, and then the end user chains in my build-time NuGet package which “discovers” these code generation extensions and loads the code generator assemblies to do the work on my scaffolding.

In the conversion, I hit two major roadblocks from .netstandard limitations:

1. Assembly.LoadFile is missing. I understand this is coming in .netstandard 2.0 but is there any supported alternative in the meantime for an MSBuild Task to load some assembly based on its path? I mean, MSBuild Core itself can do it, so how is that done so I can emulate it?
2. No AppDomain support. This is super useful for two reasons: I can control the version of Roslyn assemblies that are loaded to the ones I was compiled against, thus avoiding assembly load failures. It also lets me unload these extension assemblies when I’m done with them so they don’t lock files on disk when the build is over (including VS in proc design-time builds). If MSBuild Core similarly keeps msbuild.exe processes running after a build, we have a significant problem, but if it doesn’t, I might omit AppDomain support from just the .netstandard build of this MSBuild Task, then cross my fingers and hope for the best about the Roslyn assembly versions.

Thoughts?

[tmat]

It seems it did at one time and there were problems so the default context was used for everything: 8099cb3 EDIT: I think it previously used one extra non-default load context and not one for each task. Regardless, it seems the problems that blocked that would also block doing one per task.

It seems to me that the use of ALC per task wouldn’t be blocked anymore since the CoreCLR bug has been fixed.

Except when someone needs version 2.3.0.0 and finds it, and loads it. Then later when another assembly needs 2.4.0.0 and can find it, but isn’t allowed to load it because one is already loaded.

You can’t replace an assembly with another assembly in-place, other than doing EnC on the difference 😃. I think in a plugin system like msbuild the plugins need to be isolated in different ALCs and only msbuild assemblies that implement types used to communicate between the plugins be loaded in a default ALC. In such a model each ALC would only load assemblies that are known at build time of the plugin.

[nguerrera]

EDIT: except that it copies a bunch of framework assemblies as well that I’m sure msbuild core already ensures are available elsewhere, but I’ll live with that for now.

I’m bumping in to this myself: https://github.com/dotnet/sdk/issues/933