Not needed runtime is being downloaded and installed

[alienghub]

Description:
Downloads and installs not needed runtime

Task version:
4.3.1

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '9.0.203'

Expected behavior:
Tested host has .NET SDK installed:
9.0.203 [C:\Program Files\dotnet\sdk]

Either of these two runtimes on the tested host get used:
Microsoft.NETCore.App 9.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Actual behavior:
dotnet-install: Downloaded file https://builds.dotnet.microsoft.com/dotnet/Runtime/8.0.16/dotnet-runtime-8.0.16-win-x64.zip size is 33292304 bytes.

[aparnajyothi-y]

Hello @alienghub, Thank you for creating this issue and we will look into it :)

[aparnajyothi-y]

Hello @alienghub, Thank you once again for reporting this issue!

This behavior is expected in setup-dotnet@v4. The install script is designed to run twice with different settings:

• Initial Installation: A minimal installation of the latest LTS runtime is performed to ensure a stable and ready-to-use dotnet executable is available.

• SDK Installation: The requested SDK version (in this case, 9.0.203) is then installed using that executable.

This approach was introduced to address issues reported in #387, where setup-dotnet@v3 would overwrite the dotnet executable on each run—sometimes causing failures due to the executable being in use. In v4, we resolved this by first installing a separate runtime and using it as the base executable for all subsequent installations (#433).

Also worth noting: the minimal runtime download happens only once per workflow, so while it may seem unnecessary at first glance, it ensures better stability and reliability across steps. We’ve documented this expected behavior in the v4.0.0 release notes and referenced it in #491.

Please feel free to reach us in case of any concerns/clarifications are needed :)

[gasparnagy]

@aparnajyothi-y This makes it clear, but somehow I feel that we increase our carbon footprint a lot for many cases when the newly installed frameworks were anyway installed to a completely separate folder and not to C:\Program Files\dotnet. Couldn't this be optimized somehow so that it is only done if there is a danger of overwrite?

[alienghub]

@aparnajyothi-y Thank you for your response. It still doesn't sound as an acceptable solution for continuous runs of the same workflow.

• Why that LTS runtime is not available in the image?
• Why setup-dotnet@vX needs to overwrite dotnet executable? Why can't it be left alone without being overwritten and installing just the runtime part, it's process killed before being overwritten, installed and ran from a custom path?
• How can I select which runtime to use (--fx-version) and which SDK without hardcoding values? Let's say latest available in the image ones.

[aparnajyothi-y]

Hello @gasparnagy, @alienghub, thank you both for your thoughtful follow-ups.

@gasparnagy, The minimal LTS runtime can seem redundant when SDKs install to isolated paths, but it currently serves as a safeguard against overwrite issues. We understand the concern and will keep this in mind for future optimizations.

@alienghub, The LTS runtime isn’t included in the image to avoid bloating it with all possible SDK/runtime combinations. Instead, setup-dotnet performs targeted installs to maintain flexibility. The minimal runtime used in v4 helps prevent overwriting the existing dotnet executable—a common issue in v3. Considering more flexible install options, like dynamic runtime/SDK selection and custom paths, introduces added complexity, especially in ensuring cross-platform consistency. We’ll evaluate such enhancements based on feasibility and priority, and truly appreciate your insights as we shape the path forward.

Please let us know if you have any further concerns and clarifications needed.

[gasparnagy]

@gasparnagy, The minimal LTS runtime can seem redundant when SDKs install to isolated paths, but it currently serves as a safeguard against overwrite issues. We understand the concern and will keep this in mind for future optimizations.

@aparnajyothi-y Thank you. This is certainly appreciated, but I feel this promise a bit too wage. Besides the increased carbon footprint I have mentioned, millions of users suffer from the extended build times who simply use the task to add .NET runtimes that is not in the image by default, e.g. .NET 9. There is not even a slight chance of overwriting. Not even mentioning the ones who are on paid plan, so need to pay extra. It would be a simple fix to detect these situations and make the world better right now. Not in the future... Microsoft has been criticized already that the build tools are optimized for more azure resource usage (there is a very similar discussion for the Azure DevOps .NET framework install task). I think acting quickly on this would also help to disproof these theories, so would be a win for everyone. So please consider it once more.

[aparnajyothi-y]

Hello @gasparnagy, Thank you again for your thoughtful feedback. The current behavior in setup-dotnet@v4, where a minimal LTS runtime is installed before the requested SDK, is a deliberate design choice intended to ensure a stable and conflict-free setup experience. As outlined in the above issues, this approach addresses previous reliability concerns and helps maintain consistent behavior across environments.

We recognize that in scenarios where there's clearly no overwrite risk, the additional install step may appear redundant. However, this implementation favors reliability and predictability by default, which is critical for a broad range of workflows and platforms.

That said, if there’s enough demand from the community, we’re open to revisiting this in the future. Any potential change would need to be weighed carefully against the trade-offs in complexity, consistency, and long-term maintenance.
Please feel free to reach us in case of any concerns or clarifications needed :)