dotnet.exe silently ignores global.json with a two-digit sdk version

[maltalex]

Describe the bug

dotnet.exe silently ignores global.json with a "wrong" sdk version like "6.0" or "3.1" (as opposed to "6.0.0" or "3.1.0").

To Reproduce

Install .Net SDK, create an empty directory with a global.json file with a two digit SDK version:

{
  "sdk": {
    "version": "6.0"
  }
}

Now, run dotnet --info in the directory and observe output similar to the following:

.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.6c33ef20

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

.NET workloads installed:
 Workload version: 8.0.100-manifests.6c33ef20
There are no installed workloads to display.

Host:
  Version:      8.0.0
  Architecture: x64
  Commit:       5535e31a71

...

global.json file:
  Not found

Note that dotnet reports that global.json hasn't been found. Commands like dotnet --version or dotnet build will silently use the latest SDK instead of requiring .NET 6 as was intended by global.json. The expected behavior in this case would be to either treat "6.0" as "6.0.0" or to show an error to point out the invalid version number.

[ShreyasJejurkar]

I guess it would be safe to consider 0 if the patch version is not available. Moreover, I guess if the Major version is mentioned, then it will be safe to consider the other version to be at 0.

For example in global json "version": "6" would be equivalent to "version": "6.0.0"

[KalleOlaviNiemitalo]

Suppose that change is implemented in .NET 9 for example, the computer has both .NET 6 SDK and .NET 9 SDK installed, global.json says "version": "6", and the dotnet.exe of .NET 9 correctly treats that as meaning "6.0.0" — then will .NET 6 SDK parse global.json again and fail somehow because it does not support the abbreviated syntax?

[ShreyasJejurkar]

It needs to be backported to the supported version of .NET I guess to get this working.

I wonder why this was not the default behavior in SDK, strange.

[ShreyasJejurkar]

I guess, this issue needs to be moved to dotnet/runtime repo, as global.json printing is done there and hopefully parsing as well.

runtime/src/native/corehost/fxr/command_line.cpp

Lines 323 to 328 in 955604c

	trace::println(_X("\n")
	_X("global.json file:\n")
	_X(" %s"),
	global_json_path.empty() ? _X("Not found") : global_json_path.c_str());

[ShreyasJejurkar]

After doing more research below is the line where we parse global.json file and read it's version tag.

runtime/src/native/corehost/fxr/sdk_resolver.cpp

Line 284 in 955604c

if (!fx_ver_t::parse(version_value->value.GetString(), &requested_version, false))

Below is the line where we parse the actual version string

runtime/src/native/corehost/fxr/fx_ver.cpp

Lines 272 to 273 in 955604c

	bool parse_internal(const pal::string_t& ver, fx_ver_t* fx_ver, bool parse_only_production)
	{

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Describe the bug

dotnet.exe silently ignores global.json with a "wrong" sdk version like "6.0" or "3.1" (as opposed to "6.0.0" or "3.1.0").

To Reproduce

Install .Net SDK, create an empty directory with a global.json file with a two digit SDK version:

{
  "sdk": {
    "version": "6.0"
  }
}

Now, run dotnet --info in the directory and observe output similar to the following:

.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.6c33ef20

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

.NET workloads installed:
 Workload version: 8.0.100-manifests.6c33ef20
There are no installed workloads to display.

Host:
  Version:      8.0.0
  Architecture: x64
  Commit:       5535e31a71

...

global.json file:
  Not found

Note that dotnet reports that global.json hasn't been found. Commands like dotnet --version or dotnet build will silently use the latest SDK instead of requiring .NET 6 as was intended by global.json. The expected behavior in this case would be to either treat "6.0" as "6.0.0" or to show an error to point out the invalid version number.

Author:	maltalex
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[KalleOlaviNiemitalo]

If global.json specifies "version": "9.0" and you have versions 9.0.100 and 9.0.200 installed, then which one should it run — should a less-than-three-part version number imply some kind of roll-forward when "rollForward" is not explicitly specified?

Perhaps it's better to just report an error about the unsupported version number format; then the roll-forward ambiguity won't arise.

[ShreyasJejurkar]

If global.json specifies "version": "9.0" and you have versions 9.0.100 and 9.0.200 installed, then which one should it run

Yeah, this is correct, I missed this totally. I am not sure why we start from .100 patch version instead of going from 0,.

But anyway, I guess it would be good if we just showed an error if the version specified it's just 2 digits.