setup-dotnet
setup-dotnet copied to clipboard
actions
Incorrect Dotnet Version Displayed in GitHub Actions Workflow
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:
- [x] Ubuntu
- [ ] macOS
- [ ] Windows
Runner type:
- [x] Hosted
- [ ] Self-hosted
Steps to Reproduce:
- Use the official example from the documentation.
- Specify multiple .NET versions in the workflow matrix.
- 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.
Hello @adilhusain-s Thank you for creating the issue and we will investigate the issue :)
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.
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.
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.
@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.
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.
Hello @BrandonDusseau!, this is a polite reminder to verify if the suggested solution in the comment has addressed your issue.
@mahabaleshwars apologies for the delayed response. Things have been quite busy over here! When we upgraded our projects to .NET 8 recently, the problem naturally resolved and I was able to upgrade to setup-dotnet v4. As part of that change I added global.json files to all of the applications in our monorepo so this won't happen in the future.
What I really want to see come out of this issue is the release notes for v4 being updated to mark installing the LTS version as a breaking change, because that's what it is. Projects that are using a version of .NET earlier than the LTS and that are not using a global.json file will either fail to build or will unexpectedly produce artifacts using the wrong .NET version.
Release notes are the primary documentation for users upgrading from previous versions of a tool. If I don't see anything obvious about the behavior changing between versions, I'm not likely to look at the readme again. I don't think I'm unusual in this sense.
@BrandonDusseau
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.
where you using setup-dotnet@v3 or v4 when this occurred? today I started having issues where all my projects won't build now, when they were hours ago, and are showing errors on pages that were not even modified. is this similar to what you were experiencing?
where you using setup-dotnet@v3 or v4 when this occurred? today I started having issues where all my projects won't build now, when they were hours ago, and are showing errors on pages that were not even modified. is this similar to what you were experiencing?
I was using v4 at the time we were having problems. In our case, we were failing on our dotnet format step because it was using the wrong dotnet CLI version. Unless you upgraded the setup-dotnet action in your workflow between your builds passing and your builds failing, I'm not sure this is your problem.
You can be sure if you add a global.json file to your solution root directory and specify the SDK version you want to use. If the problem goes away, you'll know it's a versioning issue. It sounds like doing this is good practice anyway, so that local usage of the dotnet CLI uses the correct version for your project if you have multiple SDKs installed.
Hello @BrandonDusseau! Appreciate your suggestion about the required change. We have now updated the release notes to specify that installing the LTS version is a breaking change.
Hello @adilhusain-s, kindly review the provided response. It should address the problem you're experiencing.
@mahabaleshwars
could you please update the official documentation for setup/dotnet action as per above discussion?
Hi @adilhusain-s, the latest version, 8.0.1, is pre-installed on GitHub runners. You can view the changes in the release notes. If a previous version of the SDK is required, you can specify this in a global.json file. Please refer to the documentation where the use of global.json is explained.
@mahabaleshwars @aparnajyothi-y I was talking about this official docs link could we get it updated?
Hello @adilhusain-s, thank you for your suggestion. However, the document you referred to is intended to guide users on installing multiple .NET versions. The specific .NET SDK version to be used is determined by the global.json file, not this document. Therefore, an update to this document may not be necessary at this time. For more comprehensive details, please refer to the setup-dotnet repository. we are now closing this issue since it has fulfilled its intent. Please feel free to reach us if you are facing any concerns.