Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
baronfel opened this issue Feb 17, 2023 · 5 comments
Open
Assignees
Labels
Area-SdkResolvers help wanted Issues that we would accept external contributions on. Also known as up-for-grabs.
Milestone

Comments

@baronfel
Copy link
Member

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.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-SdkResolvers untriaged Request triage from a team member labels Feb 17, 2023
@KalleOlaviNiemitalo
Copy link
Contributor

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

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
Copy link
Member

xoofx commented Dec 6, 2023

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

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
Copy link
Member Author

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

@baronfel
Copy link
Member Author

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 baronfel removed the untriaged Request triage from a team member label Jan 31, 2024
@baronfel baronfel added this to the 8.0.3xx milestone Jan 31, 2024
@baronfel
Copy link
Member Author

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

@baronfel baronfel added the help wanted Issues that we would accept external contributions on. Also known as up-for-grabs. label Jan 31, 2024
@marcpopMSFT marcpopMSFT modified the milestones: 8.0.3xx, 8.0.4xx Jun 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-SdkResolvers help wanted Issues that we would accept external contributions on. Also known as up-for-grabs.
Projects
None yet
Development

No branches or pull requests

4 participants