Skip to content

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

Open

Description

@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.

Activity

  1. JoeRobich commented on Sep 18, 2026

    @JoeRobich
    Member

    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?

  2. baywet commented on Sep 18, 2026

    @baywet
    Author

    @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.

  3. JoeRobich commented on Sep 18, 2026

    @JoeRobich
    Member

    @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

  4. jasonmalinowski commented on Sep 18, 2026

    @jasonmalinowski
    Member

    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?

  5. baywet commented on Sep 18, 2026

    @baywet
    Author

    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.
  6. jasonmalinowski commented on Sep 18, 2026

    @jasonmalinowski
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions