Need MSBuildLocator provide a way to register a known SDK location

[lifengl]

Hey,

In C# DevKit scenario, we ran dotnet --version to compute runtime to use to load the project system. And we also run dotnet --list-sdks for other reasons. So we actually know the location of the SDK. (At least the fallback one if MSBuildLocator doesn't fully simulate the dotnet command). If there is a method to allow us to RegisterDotNetSdk(string sdkPath), we can potentially skip repeating searching the SDK, or have a fallback logic, when the searching logic doesn't match the dotnet command, which could happen in some odd installation scenarios, and make the extension more reliable on various platforms.

The problem is that we cannot create VisualStudioInstance (internal constructor), and call RegisterInstance. If we call RegisterMSBuildPath, we need repeat ApplyDotNetSdkEnvironmentVariables, which is private. And we don't want to repeat these logic done inside MSBuildLocator.

This would be a simple wrap for what has already been implemented inside MSBuildLocator.

[lifengl]

• @YuliiaKovalova , @ladipro

[rainersigwald]

If we call RegisterMSBuildPath, we need repeat ApplyDotNetSdkEnvironmentVariables, which is private.

This sounds like a bug to me; on Framework I believe that method does everything that's necessary to call MSBuild and it should be the same on core.

[lifengl]

yes, if RegisterMSBuildPath covers the environment variable logic, it will work for us perfectly.

[YuliiaKovalova]

Hi @lifengl ,

We are discussing the priority of the ticket internally. I'll let you know when we address it.

[YuliiaKovalova]

Hi @lifengl,

The package with the change has been released: https://github.com/microsoft/MSBuildLocator/releases/tag/v1.7.8