Workload install should respect specific .NET sdk version with no rollforward

[thomasbach-dk]

Description:
We are using setup-dotnet with global-json-file set. In global.json we have set a specific .NET feature band version (e.g. 10.0.201) with no rollForward allowed. We are experiencing an issue with the workload feature of setup-dotnet, since it does not respect the specifically set dotnet feature band version.

Task version:
5.2.0

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:
Add a global.json file:

{
  "sdk": {
    "version": "10.0.201",
    "rollForward": "disable",
    "allowPrerelease": false
  }
}

Add a workflow using setup-sdk and the workloads feature:

     - name: Install .NET SDK
        uses: actions/setup-dotnet@v5
        with:
          global-json-file: source/global.json
          workloads: maui

Check the log output to confirm that workloads from dotnet feature band 10.0.202 are installed.

dotnet-install: .NET Core SDK with version '10.0.201' is already installed.
Refreshing workload manifests...
/Users/runner/.dotnet/dotnet workload update

Skipping NuGet package signature verification.
Updated advertising manifest [microsoft.net](http://microsoft.net/).workloads.
Installing workload version 10.0.202.

Expected behavior:
When a specific version of dotnet is applied in global.json and the global.json file is referred by setup-dotnet, it should respect that specific version for both installation of .NET SDK and workloads.

Actual behavior:
When a specific version of dotnet is applied in global.json and the global.json file is referred by setup-dotnet, that specific version respected for installation of .NET SDK but not the workloads.

[Frulfump]

I think a correct title would be for it to respect disable, rollForward seems to be broken see other issues PR in this repo but those seem to indicate that rollForward is essentially disabled by default.

The feature band is the 2 in the version 10.0.201 some docs here but there are more docs in other places.
https://learn.microsoft.com/en-us/dotnet/core/tools/global-json#rollforward

But something seems to work differently for workloads, maybe they are versioned differently in global.json?

[lmvysakh]

Hello @thomasbach-dk ,
Thank you for reporting this issue. We will investigate it and get back to you as soon as we have some feedback.

[gowridurgad]

Hi @thomasbach-dk, Based on the implementation of setup-dotnet, when the workloads input is used, this action automatically runs dotnet workload update before installing the specified workloads to ensure manifests are refreshed and existing workloads are updated to their latest compatible versions. This is expected behavior from the action itself.

The dotnet workload update command updates all installed workloads to the newest available versions. For reference:
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-workload-update

The subsequent dotnet workload install installs packs based on the workload manifest associated with the SDK feature band, not the exact SDK patch version. In this case, although the SDK is pinned to 10.0.201 via global.json (and correctly used), it belongs to feature band 10.0.200, and workloads are resolved using the workload manifests associated with feature band 10.0.200. For more information, see:
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-workload-install#results-vary-by-sdk-version

This behavior is working as designed. If there are any doubts or further questions, please feel free to reach out.