`DOTNET_ROOT` Not Added by `paths` in `global.json`

[nagilson]

Context

sdk: paths was added to global.json as specified within this design document as an optional setting to enable a path to an SDK: https://github.com/dotnet/designs/blob/main/accepted/2025/local-sdk-global-json.md

{
    "sdk": {
        "paths": [ "path/to/sdk/root", "$host$" ],
        "errorMessage": "<message>"
    }
}

That was implemented into the muxer here: #113512

Issue

This feature does NOT set DOTNET_ROOT, which means the runtime related experiences can fail since the muxer and application hosts do not recognize this SDK location during runtime selection. By runtime experiences, I mean running, debugging, or testing your application.

We had a partner sync where @agocke decided we wouldn't modify DOTNET_ROOT based on this. One reason is that it's a fundamental design principle of .NET to be a multiplexing system, and if we diverge from that design by encouraging multiple install locations via this feature, we start to have a lot more problems. And the suggestion was that we can only solve this in a patchwork way. That we would rather invest in setup.net or the .NET GitHub Action/AzDo task(s). For a bootstrapper such as dnvm, we could fix the parity issue by setting DOTNET_ROOT, or adding dotnet use, but that would only fix the specifically managed bubble. Plus, we don't think there's any particular reason to believe that just because you ran a dotnet binary, you want all subsequent nested process invocations to use the same one.

At the end of that meeting, I quote from @baronfel and @agocke, 'locally installed SDKS are not the correct solution to the problem of managing and working with specific versions of SDKS ahead of like public previews for our ecosystem', and 'directionally we don't want to continue investing in trying to make SDK paths work for all of our tooling.'

My question is, are we deprecating or officially supporting this feature? It is already in .NET 10. The window is closing to remove the feature or modify its behavior to warn about these scenarios. Are we leaving it as unofficial but still implemented? Are we deprecating it? Are we officially supporting it with the caveat of DOTNET_ROOT, leaving the window open to support it via dnvm or dnUp? What is our messaging to customers?

Note that there was a lot of excitement about the feature in the above PR. I'm not saying I don't see the value of it and I don't think anybody in that discussion was getting at that.

cc @jaredpar who seems to not have been involved in that discussion.

Related

#43332 remarks on how it would be nice to have the ability to control the runtime selection via the global.json file, but it is not about this specific issue.

[agocke]

We had a partner sync where @agocke decided we wouldn't modify DOTNET_ROOT based on this

For clarity, the most important reason why the host doesn't do this is that global.json is an SDK-only feature, while DOTNET_ROOT is a runtime feature. The SDK could choose to set DOTNET_ROOT, but that wouldn't address the core scenario.

Are we officially supporting it with the caveat of DOTNET_ROOT

This was part of the explicit design of the feature (see dotnet exec) section. If the SDK wants to make a change we can look at alternatives, but the host feature is fully implemented as it was designed.

[nagilson]

We had a partner sync where @agocke decided we wouldn't modify DOTNET_ROOT based on this

For clarity, the most important reason why the host doesn't do this is that global.json is an SDK-only feature, while DOTNET_ROOT is a runtime feature. The SDK could choose to set DOTNET_ROOT, but that wouldn't address the core scenario.

Are we officially supporting it with the caveat of DOTNET_ROOT

This was part of the explicit design of the feature (see dotnet exec) section. If the SDK wants to make a change we can look at alternatives, but the host feature is fully implemented as it was designed.

Is there something we should do to clarify what the feature does and does not support (scenarios related to running, debugging, or testing) with the sdk paths feature? Perhaps update this document https://learn.microsoft.com/en-us/dotnet/core/tools/global-json#paths to reflect that?

[nagilson]

dotnet/sdk#49634 also seems relevant and a good solution for the testing scenario 😉

[agocke]

dotnet/docs#47624 Should clarify the host behavior, which seems like the only outstanding question on the runtime side.

[nagilson]

Thank you, I appreciate that, and I think we can close this issue then.

I think #88754 (comment) is the next step, based on what you, @/jaredpar and @/elinor-fung suggested here. (Making what was internal public)