Incorrect Dotnet Version Displayed in GitHub Actions Workflow

[adilhusain-s]

Description:
I was attempting to use multiple .NET versions in my GitHub Actions workflow, and I observed that the dotnet --version command consistently prints the version of .NET SDK 8.0, even though I specified other versions. I followed the official workflow example from the documentation, where it successfully uses 3.0 and 6.0 versions. However, in my workflow run (link: workflow run), it consistently displays the version as 8.0.

Task version:
[Specify the task version]

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Steps to Reproduce:

1. Use the official example from the documentation.
2. Specify multiple .NET versions in the workflow matrix.
3. Run the workflow.

Expected Behavior:
The dotnet --version command should correctly display the specified .NET versions in the workflow matrix.

Actual Behavior:
The dotnet --version command consistently displays the version as 8.0.

[aparnajyothi-y]

Hello @adilhusain-s
Thank you for creating the issue and we will investigate the issue :)

[mahabaleshwars]

Hi @adilhusain-s,
Github runners have 8.0.1 pre installed which is the latest version. You can refer the official link of the runners here.
SDK commands include dotnet new and dotnet run. The .NET CLI must choose an SDK version for every dotnet command. It uses the latest SDK installed on the machine by default, even if:
The project targets an earlier version of the .NET runtime.
The latest version of the .NET SDK is a preview version.

When an earlier version of the SDK is needed, you to specify that version in a global.json file.

The process for selecting an SDK version is:
dotnet searches for a global.json file iteratively reverse-navigating the path upward from the current working directory.
dotnet uses the SDK specified in the first global.json found.
dotnet uses the latest installed SDK if no global.json is found.

Please refer this link for official reference.

[BrandonDusseau]

I think this should be considered a breaking change even though it isn't documented that way. My team's workflows are built with the assumption that only the dotnet version we requested will be installed. My team is rolling back to v2 because our workflows are now building code using the wrong .NET version.

Either this change should be reverted, or it should be moved to the "breaking changes" section of the release notes.

[mahabaleshwars]

Hello @BrandonDusseau! The modifications are officially from .NET/Microsoft and not from setup-dotnet, hence they can't be classified as a breaking change. Please feel free to reach us if you face any other issues.

[BrandonDusseau]

@mahabaleshwars I'm not certain that's correct. When we used setup-dotnet@v2 and specified dotnet-version: 7.0.203, we would ONLY get 7.0.203 installed and our dotnet commands would execute with that. After updating to v4 and specifying the same dotnet-version parameter, it would install both 7.0.203 and 8.x, causing dotnet commands to use 8.x and breaking builds.

At this point in time we did not use global.json files because they had not been necessary.

It seems like v4 installing the latest LTS version (see #433 - I haven't taken a lot of time to try and interpret this PR so I may be wrong) may be related to this, but I'm not sure. Please correct me if I'm wrong, but I believe this is new setup-dotnet behavior and not a change on the Microsoft side.

This does seem like a breaking behavior change for any projects not using 8.0+ and that do not have a global.json file present.

[mahabaleshwars]

Hello @BrandonDusseau! Here's what you can expect with setup-dotnet@v4:

It ensures a minimal installation of the latest runtime version to get the most up-to-date stable dotnet executable.
It installs the necessary SDK based on your needs.
This approach was implemented to resolve issue #387. Prior to this, setup-dotnet@v3 would overwrite the dotnet executable every time the action was run, leading to action failures if the executable was still in use. In setup-dotnet@v4, we addressed this problem by adding an additional install-script that installs the LTS version of the dotnet executable and uses it for subsequent dotnet installations (See #433). The first install-script only executes the actual download once per workflow. However, if you need an earlier version of the SDK, you'll have to specify it in a global.json file. For more information, please refer to the setup-dotnet documentation.