global.json is ignored unless the SDK version is an exact match for a currently installed SDK

[crozone]

Issue Title

global.json is ignored unless the SDK version is an exact match for a currently installed SDK.

General

global.json SDK version and rollForward behaviour appears to be ignored if the version string is not an exact match for one of the .NET SDK versions currently installed on the machine. This has unintended consequences when building code on different machines with different dotnet SDKs installed.

This occurs on dotnet host 5.0.0-rc.1.20451.14, I have not yet tested on previous dotnet hosts.

Host (useful for support):
  Version: 5.0.0-rc.1.20451.14
  Commit:  38017c3935

Example

The simplest example is if global.json specifies an SDK version 3.1.000, because 3.1.000 is not an SDK version that exists.

global.json:

{
  "sdk": {
    "version": "3.1.000",
    "rollForward": "latestFeature"
  }
}

For reference, here are the currently installed SDKs on my machine:

.NET SDKs installed:
  2.1.802 [C:\Program Files\dotnet\sdk]
  3.1.100 [C:\Program Files\dotnet\sdk]
  3.1.200 [C:\Program Files\dotnet\sdk]
  3.1.201 [C:\Program Files\dotnet\sdk]
  3.1.402 [C:\Program Files\dotnet\sdk]
  5.0.100-rc.1.20452.10 [C:\Program Files\dotnet\sdk]

Expected behaviour:

The dotnet host should pick the latest feature version of dotnet core 3.1, which is 3.1.402.

dotnet --info should start with the text:

.NET Core SDK (reflecting any global.json):
 Version:   3.1.402
 Commit:    9b5de826fd

Observed behaviour:

The dotnet host picks the latest installed version of dotnet, which is 5.0.100-rc.1.20452.10.
The SDK version and rollForward behaviour appears to be ignored.

dotnet --info starts with the text:

.NET SDK (reflecting any global.json):
 Version:   5.0.100-rc.1.20452.10
 Commit:    473d1b592e

This issue occurs with any SDK version that is not currently installed on the machine For example, using global.json:

{
  "sdk": {
    "version": "3.1.201",
    "rollForward": "latestFeature"
  }
}

will roll forward to 3.1.402 on my local machine because SDK 3.1.201 is installed, but will jump all the way to 5.0.100-rc.1.20452.10 on our build server because SDK 3.1.201 is not present on that machine. This is problematic because the build server (and also development machines) must have all SDKs installed to account for all possible variations of global.json.

[sfoslund]

This is expected behavior as the third value of the SDK version (x.x.Xxx) is the feature band. The roll forward behavior only applies to the patch, which is the last two digits of the version (x.x.xXX). Please refer to the docs for more information, thanks

[crozone]

This is expected behavior as the third value of the SDK version (x.x.Xxx) is the feature band. The roll forward behavior only applies to the patch, which is the last two digits of the version (x.x.xXX). Please refer to the docs for more information, thanks

Roll forward behaviour was specifically set to latestFeature.

The docs specify that the latestFeature option "Uses the highest installed feature band and patch level that matches the requested major and minor with a feature band and patch level that is greater or equal than the specified value.
If not found, fails.".

So, if I'm reading that correctly, the latest dotnet version with the same major (3) and minor (1) version should be selected after the given version.

If roll forward behaviour only applies to the patch, then latestFeature should not be listed as an option in the official documentation.

[sfoslund]

Apologies, I misunderstood your issue, reopening.

So to clarify, the issue is that you are specifying a 3.1 SDK in your global.json and it is rolling forward to 5.0?

[crozone]

Apologies, I misunderstood your issue, reopening.

So to clarify, the issue is that you are specifying a 3.1 SDK in your global.json and it is rolling forward to 5.0?

No worries at all, and yep. If a 3.1 SDK is specified in global.json and that exact 3.1.Xxx version isn't available, it doesn't roll forward to the latest 3.1.Xxx SDK as expected, it rolls all the way forward to 5.0.

However I was just doing some additional testing (double checking the other rollForward behaviours) and can no longer seem to repro this. It does fail consistently when the feature level is "0", aka version 3.1.0XX, but I'm guessing that 0 may be an invalid feature level which isn't supposed to work anyway, or it's an edge case. I've set up another environment on Linux with 2.1, 3.1, and 5.0 installed and can't repro it there either, except for when the feature level is 0. Then it always rolls forward to 5.0.

I'm assuming that I've given myself false memories of testing this with a non-zero feature level and this is actually a non-issue after all 😣 From what I can tell, the docs don't specifically prohibit a "0" feature level, so this may still be an issue (either on the SDK side or the docs side), but I'll close this issue for now and re-open a new one for the feature level if you think it's warranted.

[michael-hawker]

Not sure if should open new issue, but kind of appears to be similar to this one.

Noticed in our linux environment in our CI that rollForward was being ignored. Our global.json:

{
  "sdk": {
    "version": "6.0.403",
    "rollForward": "latestFeature"
  }
}

We can see 6.0.405 is installed, but then msbuild is still looking for 403 and ignoring rollForward:

However, in the Windows environment, everything built fine on 405:

When I updated our global.json to call out 405 specifically, then it worked on linux as we'd expect. But we expected it to work before and rollforward from 403 to 405.

Is this an issue with global.json and dotnet/msbuild specific to linux?