Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDK "roll forward" logic broken #458

Open
3 tasks done
menehune23 opened this issue Oct 6, 2021 · 5 comments
Open
3 tasks done

SDK "roll forward" logic broken #458

menehune23 opened this issue Oct 6, 2021 · 5 comments

Comments

@menehune23
Copy link
Contributor

menehune23 commented Oct 6, 2021

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
Copy link

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

@ForestEckhardt
Copy link
Member

ForestEckhardt commented Feb 28, 2023

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

@ForestEckhardt ForestEckhardt moved this from ❓ Not scoped to 📝 Todo in CF Buildpacks Workstreams Feb 28, 2023
@ForestEckhardt ForestEckhardt moved this from 📝 Todo to ❓ Not scoped in CF Buildpacks Workstreams Feb 28, 2023
@johnnyr0x
Copy link

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

@TimHess
Copy link

TimHess commented Mar 14, 2024

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
Copy link

TimHess commented Dec 12, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Not scoped
Development

No branches or pull requests

4 participants