ubuntu-latest not respecting latest installed .NET SDK - Results in build error

[thomhurst]

Description

Here's my build. It's on a matrix to build on ubuntu, windows and mac.

As you can see, windows and mac pass. But ubuntu complains that it only has .NET 8 and not .NET 9.

However you can see in the step above I'm installing the .NET 9 SDK by doing:

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: 9.0.x

That runs and says:

dotnet-install: Attempting to download using aka.ms link https://builds.dotnet.microsoft.com/dotnet/Sdk/9.0.102/dotnet-sdk-9.0.102-linux-x64.tar.gz
dotnet-install: Remote file https://builds.dotnet.microsoft.com/dotnet/Sdk/9.0.102/dotnet-sdk-9.0.102-linux-x64.tar.gz size is 210604728 bytes.
dotnet-install: Extracting archive from https://builds.dotnet.microsoft.com/dotnet/Sdk/9.0.102/dotnet-sdk-9.0.102-linux-x64.tar.gz
dotnet-install: Downloaded file size is 210604728 bytes.
dotnet-install: The remote and local file sizes are equal.
dotnet-install: Installed version is 9.0.102
dotnet-install: Adding to current process PATH: /usr/share/dotnet. Note: This change will be visible only when sourcing script.
dotnet-install: Note that the script does not resolve dependencies during installation.
dotnet-install: To check the list of dependencies, go to https://learn.microsoft.com/dotnet/core/install, select your operating system and check the "Dependencies" section.
dotnet-install: Installation finished successfully.

Then the next step is to run my .NET 9 app, and it fails with a .NET 8 SDK error:

Run sudo -E dotnet run -c Release --allCategories=Singleton
Error: /usr/lib/dotnet/sdk/8.0.111/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.TargetFrameworkInference.targets(166,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 9.0. Either target .NET 8.0 or lower, or use a version of the .NET SDK that supports .NET 9.0. Download the .NET SDK from https://aka.ms/dotnet/download [/home/runner/work/Inject.NET/Inject.NET/Benchmarks/Benchmarks.csproj]

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• Ubuntu 24.04
• macOS 12
• macOS 13
• macOS 13 Arm64
• macOS 14
• macOS 14 Arm64
• macOS 15
• macOS 15 Arm64
• Windows Server 2019
• Windows Server 2022
• Windows Server 2025

Image version and build link

https://github.com/thomhurst/Inject.NET/actions/runs/12807345586/job/35707734799

Is it regression?

Yes

Expected behavior

https://github.com/thomhurst/Inject.NET/actions/runs/12738696095

Actual behavior

.NET 9 SDK is installed but isn't used when trying to run a .NET 9 app

Repro steps

Install .NET 9 SDK

Run .NET 9 app

[Prabhatkumar59]

Hi @thomhurst - Thank you for bringing this issue to our attention. We will look into this issue closely and will update you after investigating.

[thomhurst]

It's happening on another repo of mine too if it's helpful: https://github.com/thomhurst/TUnit/actions/runs/12848634548/job/35826224078

[Zastai]

Is the sudo part of your explicit build command, or only the dotnet run part?

Because it does say that the PATH change is not exported. So if you are running the sudo, try issuing an export PATH first.

[hemanthmanga]

Hi @thomhurst, We have added the .NET 9 version to both Ubuntu 20 and Ubuntu 22. Kindly check the PR. However, for Ubuntu 24, .NET 9 is not yet available in the package manager as it is currently not supported in the built-in Ubuntu feed. If needed, you can install it manually, use backports, or utilize setup-dotnet. For more information, please read the complete documentation. We are closing this issue, Thank you.

[thomhurst]

Hi @thomhurst, We have added the .NET 9 version to both Ubuntu 20 and Ubuntu 22. Kindly check the PR. However, for Ubuntu 24, .NET 9 is not yet available in the package manager as it is currently not supported in the built-in Ubuntu feed. If needed, you can install it manually, use backports, or utilize setup-dotnet. For more information, please read the complete documentation. We are closing this issue, Thank you.

I am installing it manually. If you look at my post I'm using the setup dotnet action

[thomhurst]

Is the sudo part of your explicit build command, or only the dotnet run part?

Because it does say that the PATH change is not exported. So if you are running the sudo, try issuing an export PATH first.

You think the sudo is breaking it? It used to run fine which is strange. I'll try it without sudo and see

[thomhurst]

Is the sudo part of your explicit build command, or only the dotnet run part?
Because it does say that the PATH change is not exported. So if you are running the sudo, try issuing an export PATH first.

You think the sudo is breaking it? It used to run fine which is strange. I'll try it without sudo and see

That did indeed resolve it. Thanks!

[Odonno]

This issue still persist for me. Do I need to add a sudo somewhere?

[thomhurst]

This issue still persist for me. Do I need to add a sudo somewhere?

I had to remove a sudo

[Odonno]

I never needed to use sudo and I still don't use it, and the actions is still failing as of now.

[Zastai]

The main thing that made the sudo break is that the action only modifies $PATH for the current shell. So when you run dotnet there it will find it.

But if you run anything else (whether sudo or a script, or...) that tries to run dotnet, it will see the global, unmodified, $PATH instead (which may or may not have any dotnet command in it; and frankly I would prefer it if the runners did not have a .NET SDK preinstalled, to avoid this confusion).

If this is what is affecting you, the solution would be to issue

export PATH

before the rest of your commands to make sure they see and use the updated version. You may also need to export some other values like DOTNET_HOME if the script sets them, but PATH will be the main one.

(Also, @Odonno, saying only "it doesn't work for me" when you were not using sudo like OP is spectacularly unhelpful; are we supposed to guess what your failure mode is?)

[Odonno]

The main thing that made the sudo break is that the action only modifies $PATH for the current shell. So when you run dotnet there it will find it.

But if you run anything else (whether sudo or a script, or...) that tries to run dotnet, it will see the global, unmodified, $PATH instead (which may or may not have any dotnet command in it; and frankly I would prefer it if the runners did not have a .NET SDK preinstalled, to avoid this confusion).

If this is what is affecting you, the solution would be to issue

export PATH
before the rest of your commands to make sure they see and use the updated version. You may also need to export some other values like DOTNET_HOME if the script sets them, but PATH will be the main one.

I will try this. Thank you for your explanation.

(Also, @Odonno, saying only "it doesn't work for me" when you were not using sudo like OP is spectacularly unhelpful; are we supposed to guess what your failure mode is?)

To be honest, I am doing anything fancy and I was expecting more people to have issues with the recent update to Ubuntu 24 (or maybe the roll forward isn't GA for everyone yet?).

Anyway, I was curious to know the reason and I am still not sure to understand it yet. I can give you some concrete for a change. Here is what my CI workflow looks like:

jobs:
    runs-on: ubuntu-4cores
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup dotnet 9.0
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: "9.0.x"

      - name: Install .NET tools
        run: dotnet tool restore

      - name: Check Formatting
        run: dotnet csharpier --check .

      - name: Install dependencies
        run: dotnet restore

      - name: Build
        run: dotnet build --no-restore

This workflow fails at the dotnet csharpier --check . step.

Hope it brings sufficient information about my problem.

[Odonno]

OK. I upgraded csharpier to the latest version and now it works fine. I suspect this is due to the preinstalled version of .NET that is now higher than the ones in Ubuntu 22.

I would prefer it if the runners did not have a .NET SDK preinstalled - I understand what you mean by that now :)

Sorry for the trouble @Zastai