Show error when using invalid `global.json` version string like `9.0.x`

[Frulfump]

Is your feature request related to a problem? Please describe

Ref: dependabot/dependabot-core#12396 (comment)
and dependabot/dependabot-core#12638 (comment)

According to this https://learn.microsoft.com/en-us/dotnet/core/tools/global-json a version string of 9.0.x doesn't seem to be supported

This field:

Doesn't have wildcard support; that is, you must specify the full version number.
Doesn't support version ranges.

(Noticed when preparing this repro that dotnet new global.json happily accepts the invalid version string, should I report that in the dotnet/templating repo? UPDATE: Created here #50460)

And as can be seen below the dotnet --info command shows that the invalid version string is silently ignored. It even prints

global.json file:
  Not found

which is surprising.

dotnet command outputs

➜ dotnet new global.json --sdk-version 9.0.x
The template "global.json file" was created successfully.

➜ dotnet new console
The template "Console App" was created successfully.
...

➜ dotnet build
...
Build succeeded in 2,6s

➜ dotnet --info
.NET SDK:
 Version:           10.0.100-preview.6.25358.103
 Commit:            75972a5ba7
 Workload version:  10.0.100-manifests.6616851e
 MSBuild version:   17.15.0-preview-25358-103+75972a5ba

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.100-preview.6.25358.103\

.NET workloads installed:
There are no installed workloads to display.
Configured to use workload sets when installing new manifests.
Workloads are configured to install and update using workload versions, but none were found. Run "dotnet workload restore" to install a workload version.

Host:
  Version:      10.0.0-preview.6.25358.103
  Architecture: x64
  Commit:       75972a5ba7

.NET SDKs installed:
  8.0.412 [C:\Program Files\dotnet\sdk]
  9.0.302 [C:\Program Files\dotnet\sdk]
  10.0.100-preview.6.25358.103 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

The Dependabot team is currently choosing to adapt to the invalid version by guessing what the user wants and use the latest .NET 9 SDK but this leads to a different SDK being used in their runs compared to what the user potentially will see locally and in their own CI. I'm arguing their approach can lead to "interesting" issues and they don't want to add a warning or error unless the SDK already does so dependabot/dependabot-core#12638 (comment)

cc @JamieMagee @brettfo @randhircs

Describe the solution you'd like

Ideally an error is provided, put it behind a TFM check (if possible, might not be as in the case with dotnet new console but just error out anyways people can fix their code, don't be afraid of that breaking people they need to move to a new SDK anyways) so it's not just tied to the SDK used and require net10.0 and above, .NET 8 goes out of support November 10:th 2026 and .NET 9 May 12:th 2026 https://dotnet.microsoft.com/en-us/platform/support/policy which is soon enough. Could consider having it as a warning for 9.0.4xx which hasn't been released yet and unlikely to meet the servicing bar for 8.0.1xx or 8.0.4xx.

Additional context

N/A

[baronfel]

we're entirely relying on the hostfxr (native component managed by the dotnet/runtime team) for all global.json parsing. That parsing is very restrictive, and we don't get a great signal if the problem was a) no global.json at all, or b) problem parsing global.json.

So I'm reading this as a request for more informative feedback from the runtime's global.json parsing libraries, is that reasonable? cc @elinor-fung.

[Frulfump]

we're entirely relying on the hostfxr (native component managed by the dotnet/runtime team) for all global.json parsing. That parsing is very restrictive, and we don't get a great signal if the problem was a) no global.json at all, or b) problem parsing global.json.

So I'm reading this as a request for more informative feedback from the runtime's global.json parsing libraries, is that reasonable? cc @elinor-fung.

Oh that's interesting good to know. Could be, I'm not well versed in the intricacies involved here, I'm more concerned with the outcome I described but understand you need to find the right place for it.

[Frulfump]

Here's a similar case where it leads a user to an error downstream when using the UseDotNet@2 task for Azure Pipelines microsoft/azure-pipelines-tasks#19292 (comment) (rollForward is ignored in that task so if they had written 9.0.100 they would get the actual 9.0.100 SDK which contains vulnerabilities @baronfel could you escalate that internally? (I wonder if that has a non-zero impact on https://dotnet.microsoft.com/en-us/platform/telemetry I assume so, 8.0.100 is at 1,2% and 9.0.100 is at 1%) microsoft/azure-pipelines-tasks#17179 I guess to some degree using global.json when it includes a rollForward strategy to actually install an SDK version is guesswork that often times works out?! i.e the user gets what they want but in actuality they can't describe that in a global.json when rollForward is used as it describes a range of versions that could be used but not what an external tool should install it just happens to be possible to interpret it that way and using the latest available in that range is usually a good idea and usually works out?)

(And https://learn.microsoft.com/en-us/dotnet/core/tools/global-json#matching-rules

If a global.json file is found and it specifies an SDK version:

If no rollForward value is set, it uses patch as the default rollForward policy. Otherwise, check each value and their behavior in the [rollForward](https://learn.microsoft.com/en-us/dotnet/core/tools/global-json#rollforward) section.

Which I don't think many people know. So in order to pin the version you actually need to specify rollForward = disable. I don't have access to test Azure Pipelines atm so I can't test how it handles a global.json with just version set.

patch docs

Uses the specified version.
If not found, rolls forward to the latest patch level.
If not found, fails.

This value is the legacy behavior from the earlier versions of the SDK.

In this case they are trying to use 9.0.0 as the version string. (But are saved locally by the rollForward option being added as otherwise dotnet commands would fail as shown below.)
However

dotnet command outputs

➜ dotnet new global.json --sdk-version 9.0.0
The template "global.json file" was created successfully.

➜ dotnet --info

Host:
  Version:      10.0.0-preview.6.25358.103
  Architecture: x64
  Commit:       75972a5ba7
  RID:          win-x64

.NET SDKs installed:
  8.0.412 [C:\Program Files\dotnet\sdk]
  9.0.302 [C:\Program Files\dotnet\sdk]
  10.0.100-preview.6.25358.103 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  C:\repos\repros\sdk\issue49816\global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

➜ dotnet new console
The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'new' does not exist or is not a managed .dll or .exe.
  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 9.0.0
global.json file: C:\repos\repros\sdk\issue49816\global.json

Installed SDKs:
8.0.412 [C:\Program Files\dotnet\sdk]
9.0.302 [C:\Program Files\dotnet\sdk]
10.0.100-preview.6.25358.103 [C:\Program Files\dotnet\sdk]

Install the [9.0.0] .NET SDK or update [C:\repos\repros\sdk\issue49816\global.json] to match an installed SDK.

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found

➜ dotnet new global.json --sdk-version 9.0.0 --roll-forward latestMinor --force
The template "global.json file" was created successfully.

➜ dotnet --info
.NET SDK:
 Version:           9.0.302
 Commit:            bb2550b9af
 Workload version:  9.0.300-manifests.fadeff71
 MSBuild version:   17.14.13+65391c53b

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.302\

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      10.0.0-preview.6.25358.103
  Architecture: x64
  Commit:       75972a5ba7

.NET SDKs installed:
  8.0.412 [C:\Program Files\dotnet\sdk]
  9.0.302 [C:\Program Files\dotnet\sdk]
  10.0.100-preview.6.25358.103 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 8.0.18 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 10.0.0-preview.6.25358.103 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  C:\repos\repros\sdk\issue49816\global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

9.0.0 SDK doesn't exist so it shouldn't recommend to install that version either. They are only "saved" because of the rollForward being set. IMO this scenario should also produce an error. Interestingly enough a version string of asddfgkdfgsdk gives me the 10 preview 6 SDK so this means that the invalid 9.0.0 string is parsed and it can use some parts of it as I do get the 9.0.302 SDK then.

Opened docs issue to see if it can be clarified in the meantime dotnet/docs#47455

[elinor-fung]

So I'm reading this as a request for more informative feedback from the runtime's global.json parsing libraries, is that reasonable?

That is definitely reasonable.

the invalid version string is silently ignored.
Ideally an error is provided

I recall we had similar feedback before. At that time, the breaking nature of the change was a concern. However, it now seems that a lot of the SDK commands also read the global.json - and will error out when malformed. At this point, I think we should probably do the breaking change so the host errors instead of ignoring it.

Edit: the SDK commands only error out on malformed JSON (not an invalid value like 9.0.x), so changing this could still be a significant breaking change.

[elinor-fung]

Related as the latest SDK including prerelease is used when global.json is ignored: #49777
cc @richlander