Record information about the resolved global.json usage in the SdkResolver

[baronfel]

Is your feature request related to a problem? Please describe.

The SDK Resolver resolves an SDK according to any global.json rules that the .NET Host finds, and the Host reports back information like the path to the global.json, the version requested by the global.json, etc.

We should ensure that the SDK resolver logs this information via MSBuild properties to aid debugging - internal MSBuild users have been stumped by why a particular SDK was chosen when global.jsons far above the project root were at fault.

Describe the solution you'd like

We should log properties (or a single item with metadata) that provide the following data from the SDK Resolver:

• the path of any resolved global.json file
• the version requested in the global.json

This would make it easier for people debugging a build to determine if a global.json is impacting the build unexpectedly.

[KalleOlaviNiemitalo]

From the source code, it looks like MSBuildSdkResolver already adds the path of global.json to SdkResult:

sdk/src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/MSBuildSdkResolver.cs

Lines 170 to 171 in 517aa20

	propertiesToAdd.Add("SdkResolverHonoredGlobalJson", "false");
	propertiesToAdd.Add("SdkResolverGlobalJsonPath", resolverResult.GlobalJsonPath);

And MSBuild converts the contents of PropertiesToAdd to MSBuild properties:

https://github.com/dotnet/msbuild/blob/56087a97257fab6a67d110a7b2c4116f707325ee/src/Build/Evaluation/Evaluator.cs#L1978-L2005

What seems to be missing is (1) a property or an item for the requested SDK version, and (2) logging of the results.

[xoofx]

Hey, I'm trying to find a documentation about how the SDK global.json is resolved and can only find the following code:

sdk/src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/MSBuildSdkResolver.cs

Lines 215 to 234 in 517aa20

	private static string GetGlobalJsonStartDir(SdkResolverContext context)
	{
	// Evaluating in-memory projects with MSBuild means that they won't have a solution or project path.
	// Default to using the current directory as a best effort to finding a global.json. This could result in
	// using the wrong one but without a starting directory, SDK resolution won't work at all. In most cases, a
	// global.json won't be found and the default SDK will be used.
	string startDir = Environment.CurrentDirectory;
	if (!string.IsNullOrWhiteSpace(context.SolutionFilePath))
	{
	startDir = Path.GetDirectoryName(context.SolutionFilePath);
	}
	else if(!string.IsNullOrWhiteSpace(context.ProjectFilePath))
	{
	startDir = Path.GetDirectoryName(context.ProjectFilePath);
	}
	return startDir;
	}

Do I understand correctly that if we pass a csproj or sln to dotnet build, it's going to locate the global.json from the csproj/sln folder, otherwise it is going to use Environment.CurrentDirectory

[baronfel]

@xoofx yes, that's correct. The comment notes that the CurrentDirectory backstop is for evaluating in-memory projects only.

[baronfel]

in dotnet/msbuild#9621 the MSBuild team added logging of all resolution results, so that covers quite a bit. The only part missing from this is the requested version, if any, from the global.json.

[baronfel]

This is a good candidate for domestic cat to pick up.