Add a dotnet.defaultGlobalJson setting for language server and test context loading

[baywet]

Feature request

Please add a workspace setting such as dotnet.defaultGlobalJson, analogous to the existing dotnet.defaultSolution setting.

This setting should allow a repository to identify the global.json that controls its .NET SDK and test-runner context when that file is located in a subdirectory rather than at the workspace root.

Proposed behavior

When dotnet.defaultGlobalJson is configured, C# Dev Kit should use that file when initializing the workspace context for:

• the language server
• project and solution loading
• Test Explorer test discovery and execution

The setting should support a workspace-relative path, for example:

{
  "dotnet.defaultSolution": "dotnet/agent-framework-release.slnf",
  "dotnet.defaultGlobalJson": "dotnet/global.json"
}

The explicit setting should take precedence over automatic global.json discovery for the affected workspace context. Existing automatic discovery should remain unchanged when the setting is absent.

Scenario

A repository may contain multiple language and tooling areas and keep its .NET configuration under a dotnet/ subdirectory. In this layout, the workspace root may contain the solution filter at dotnet/agent-framework-release.slnf and the SDK/test configuration at dotnet/global.json.

For example, the repository where this was observed has a dotnet/global.json selecting Microsoft Testing Platform, while its test projects use UseMicrosoftTestingPlatformRunner=true. Direct MTP discovery finds the tests when run from the dotnet directory, but opening the repository root provides no way to explicitly select the nested global.json context for the language server and Test Explorer.

Acceptance criteria

• Add and document dotnet.defaultGlobalJson.
• Honor it when loading the language-server workspace context.
• Honor it during Test Explorer discovery and test execution.
• Preserve current automatic discovery when the setting is absent.
• Report a clear diagnostic when the configured path does not exist or is invalid.

[JoeRobich]

A repository may contain multiple language and tooling areas and keep its .NET configuration under a dotnet/ subdirectory.

Does the dotnet CLI tooling support such a layout? Do you have an example of a public repo like this?

[baywet]

@JoeRobich for the repository github.com/microsoft/agent-framework (and semantic kernel).

And no, the dotnet CLI does not have an argument for that, it relies on the CWD.

[JoeRobich]

@baywet I think it might be best to start with opening an issue against the CDK describing the issues you are running into when opening the root folder instead of the dotnet folder. CDK owns project loading and test running when it is installed. https://github.com/microsoft/vscode-dotnettools/issues

[jasonmalinowski]

Is the bug here that we're looking for a global.json at the root rather than walking up from the configured defaultSolution and finding the right one?

[baywet]

correct, I didn't assume it could be a bug, but essentially:

1. we have a solution in a subdirectory, and a global.json next to it
2. the .vscode/settings.json defaultSolution points to that (right now this is local, I'm submitting a PR soon)
3. the extension (language server, test explorer, etc...) looks for the global.json at the root, and fails to find it.

[jasonmalinowski]

Yeah I'd just call that a bug. We'll have to chase where we put in that assumption to work it out. I don't think the language server directly has an assumption that way but will have to check.