NuGet updater doesn't handle versions like `8.0.x` in `global.json`

[brettfo]

A manual review of the logs has shown some repos with a global.json file with contents similar to:

{
  "sdk": {
    "version": "8.0.x",
    "rollForward": "latestFeature"
  }
}

The string 8.0.x doesn't parse as a NuGetVersion which causes problems in the updater.

The work here is to determine if this is a valid scenario and either support it (preferred), or if it's not valid to report dependency_file_not_parseable.

[Frulfump]

According to this https://learn.microsoft.com/en-us/dotnet/core/tools/global-json it 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.

Maybe the report could guide users to the docs and help them understand why it's invalid?

I tried out a global.json file with that version string and received no errors or warnings when using dotnet build dotnet restore or dotnet clean having the .NET 8.0.410, 9.0.300 and 10.0.100-preview.4.25258.110 SDKs installed so maybe it's worth opening an issue in the dotnet/sdk repo so they either can clarify or add a warning/error for that scenario?

[brettfo]

Given that the NuGet updater doesn't do anything with the SDK version, another approach I'm considering is simply removing the parsing code for that. We'll need to maintain support for things like MSBuild SDKS, though.

Edit: the SDK installer PowerShell scripts will need to handle this, similar to how they handle "invalid" strings like 8.0.0 and 8.0.

[Frulfump]

Ah ok, yeah your edit makes sense that the PowerShell script will need to handle it like they handle other invalid strings (I hope they present an error so the customers can correct their code and doesn't try to guess what it should install as that could lead to other unexpected issues)