SDK "roll forward" logic broken

[menehune23]

Repro steps:

1. Using the dotnet CLI, generate an app:

   dotnet new webApp -o foo --no-https  # used .NET 5 SDK

2. Add a global.json to the app source dir:

   {
     "sdk": {
       "version": "5.0.4"
     }
   }

3. Push the app:

cd foo && cf push test

Expected to download SDK 5.0.401 during staging

Instead, SDK 5.0.413 was attempted:

**WARNING** SDK 5.0.4 in global.json is not available
falling back to latest version in version line
-----> Installing dotnet-sdk 5.0.413
**ERROR** DEPENDENCY MISSING IN MANIFEST:

Version 5.0.413 of dependency dotnet-sdk is not supported by this buildpack.
The versions of dotnet-sdk supported in this buildpack are:
- 3.1.412
- 3.1.413
- 5.0.400
- 5.0.401

**ERROR** Unable to install Dotnet SDK: dependency dotnet-sdk 5.0.413 not found

(Using buildpack v2.3.35)

It seems that the roll forward logic has gotten mixed up with the major version number and took the .413 from the 3.x version line instead of the 5.x version line.

Please confirm where necessary:

• I have included a log output
• My log includes an error message
• I have included steps for reproduction

[johnnyr0x]

@sophiewigmore @ForestEckhardt - Does this still apply since we're on 6/7? If not, please close.

[ForestEckhardt]

The global.json behavior is strange. I think that we should probably make this roll forward scenario impossible if the global.json is specified. This probably warrants some further investigation and potentially a change to how we treat global.json

[johnnyr0x]

Let's move to the icebox for now. If users start running into it we can look into again.

[TimHess]

Providing a slightly different perspective on this subject (if this feels too off-topic I can create a new issue), I have an app that targets .NET 8, and am deploying to an environment that has v2.4.24 of the buildpack.

As a .NET developer, I typically do NOT expect that I need to provide a global.json unless I need to specify the sdk version/range for some specific reason. Normally I just want the app to build with whatever installed sdk is up to the task (typically the latest version) and expect it to fail if that is not possible in the build environment. I would never expect to need to add global.json to use the latest LTS.

Why don't I want to add a global.json? The logic built into the SDK generally just works and I usually don't even know what patch version I have (and it's always quite different from the runtime version) and certainly have no idea (or reason to care about specifics) what versions are in the buildpack.

Notably, the SDK is backwards compatible:

The first two positions of the .NET SDK version number match the .NET Runtime version it released with. Each version of the SDK can create applications for this runtime or any lower version.

It would be a dramatic improvement in the user experience if the buildpack can be updated in such a way that the user only needs to care about sdk versions if there's an actual problem.

[TimHess]

This is definitely still an issue, and I was bit confused why I'm having problems today...

Here's what's on my machine:

dotnet --list-sdks
6.0.428 [C:\Program Files\dotnet\sdk]
8.0.111 [C:\Program Files\dotnet\sdk]
9.0.101 [C:\Program Files\dotnet\sdk]
9.0.200-preview.0.24575.35 [C:\Program Files\dotnet\sdk]

That preview sdk is causing some issues, so I added a global.json to use something older:

{
  "sdk": {
    "allowPrerelease": false,
    "rollForward": "latestPatch",
    "version": "8.0.100"
  }
}

Which works fine locally... But on CF, v2.4.33 is installed (which should have SDK v8.0.401) and I get Unable to install Dotnet SDK: could not find sdk in same feature line as '8.0.100' -- and it doesn't seem to matter what I specify for rollForward, so maybe that property isn't evaluated at all?? The docs don't say.

On the surface, 8.0.100 -> 8.0.401 looks like a difference in patch version, so it is confusing that this wouldn't work. Maybe the docs should be updated to describe the logic around how the feature line factors in? As a developer, I generally don't care and just want to provide the major version and let things go from there.

I was able to get my app running by adding buildpack.yml, which does seem to work the way I want in CF, but doesn't help at all with local development