Allow the SDK resolver to ignore the global.json

[JoeRobich]

The commands available to the dotnet CLI are dependent on the resolved SDK. There are some commands such as dnx which should function regardless of what SDK is pinned in the global.json. This has become a problem for running the Roslyn LSP in the Copilot CLI as it uses dotnet dnx to launch the LSP, but this will fail if the folder being run against has pinned to .NET 9 or lower.

I propose adding a new flag indicating whether to ignore the global json and if it is passed, return the SDK as if no global.json was present.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-text-json
See info in area-owners.md if you want to be subscribed.

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• Allow dotnet commands to bypass the global.json version check sdk#10311

[marcpopMSFT]

More context
More and more customers are creating tooling relying on dnx. dnx only exists in .NET 10 though so agents or IDE calls that execute tools within the customer's work tree will end up failing. Additionally, some tools may end up depending on the SDK installed as more tools are MCP servers that depend on changes built into roslyn or msbuild versions that come with the SDK and aren't being backported.

We could ask all customers calling dnx to run from different working directories to work around this but there is danger in doing that. Creating a CLI muxer experience where we can specify --ignore-globaljson on the CLI would be a better experience for this. We could request an --sdk-version override but that complicates the experience as callers would have to know what versions are available.

[elinor-fung]

Creating a CLI muxer experience where we can specify --ignore-globaljson on the CLI would be a better experience for this. We could request an --sdk-version override but that complicates the experience as callers would have to know what versions are available.

I'm fine with something like --ignore-global-json. I do not want any sort of override mechanism - it makes the version resolution scenario, which is already complicated, even harder to reason about for a user.

I propose adding a new flag indicating whether to ignore the global json and if it is passed, return the SDK as if no global.json was present.

Is this also the dnx / dotnet dnx scenario? I'm missing how both a CLI flag and the native API are involved here.