You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a dotnet.defaultGlobalJson setting for language server and test context loading #9787
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:
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.
@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
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.
Activity
JoeRobich commentedon Sep 18, 2026
Does the dotnet CLI tooling support such a layout? Do you have an example of a public repo like this?
baywet commentedon Sep 18, 2026
@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 commentedon Sep 18, 2026
@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 commentedon Sep 18, 2026
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 commentedon Sep 18, 2026
correct, I didn't assume it could be a bug, but essentially:
jasonmalinowski commentedon Sep 18, 2026
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.