Today the context available to sdk resolvers is fixed by https://github.com/Microsoft/msbuild/blob/master/src/Framework/Sdk/SdkResolverContext.cs#L9

Seeing that SolutionFilePath comes from $(SolutionPath),

I wonder if we can just have an extra method on SdkResolverContext that lets resolvers query any propety:

public abstract class SdkResolverContext {
   // ...
   public abstract string GetProperty(string name);
}

This would allow resolvers to document arguments that are passed as plain msbuild properties.

Without this, we're currently using environment variables to override some of our resolver's behavior:

https://github.com/dotnet/cli/blob/09dd14bfe467e1cd264740af6ed4a8a243ccb53a/src/Microsoft.DotNet.MSBuildSdkResolver/MSBuildSdkResolver.cs#L20-L24
https://github.com/dotnet/cli/blob/09dd14bfe467e1cd264740af6ed4a8a243ccb53a/src/Microsoft.DotNet.MSBuildSdkResolver/MSBuildSdkResolver.cs#L94-L98

Our immediate use case was to have a test hook, but there are production scenarios too. The main one is pulling down the .NET Core SDK to an arbitrary, non-global location as part of the build and signaling to the resolver to choose the appropriate sdk from there and not from program files. (Now, that actually overlaps with another feature that's evolving and we will likely land in a place where you can edit global.json to get this behavior without setting any environment variables, but the mechanism here applies more generally to arbitrary resolvers with arbitrary input.)

cc @jaredpar @AndyGerlicher

EDIT (by @dsplaisted): We probably want to do this, but only for global properties. This will allow resolvers to know whether they are running in VS, for example.