Consider using MSBuildLocator

[daveaglick]

Consider using MSBuildLocator

[daveaglick]

Follow-up, here's more recent DocFx code - might want to consider rethinking some of how we're doing this and follow their lead:
https://github.com/dotnet/docfx/blob/916929a58c92afd1bb85689f53f56763771a86fa/src/Microsoft.DocAsCode.Metadata.ManagedReference/EnvironmentHelper.cs#L143

[daveaglick]

Note that MSBuildLocator is also only .NET Framework 4.6 right now. Going to open an issue to suggest .NET Standard support.

[daveaglick]

Went down this path a little ways and I don't think it's going to work for Buildalyzer. Because the MSBuildLocator approach is to delay-load MSBuild assemblies, they can't have been loaded into the current AppDomain until Buildalyzer gets a chance to figure out where MSBuild is and hook assembly resolution. However, because Buildalyzer exposes some MSBuild objects like Project, the caller typically needs to bind to the MSBuild assemblies before Buildalyzer ever gets called.

If we did want to use the assembly resolution trick from MSBuildLocator it would probably mean abstracting all MSBuild objects and hiding them as internal to Buildalyzer.

[daveaglick]

Going to close this for now - it doesn't appear as though MSBuildLocator is going to target .NET Core anytime soon.