What’s new for .NET in Ubuntu 24.04

Richard Lander

Today is launch day for Ubuntu 24.04, Noble Numbat. Congratulations to our friends at Canonical. I’d say it’s an auspicious day, but it is more noble than that! In fact, it is the first time that a .NET release is available from day one in the official Ubuntu feeds. There is no need to wait, you can start using .NET with Ubuntu 24.04 now.

You may remember that .NET 6 was added to Ubuntu 22.04, a few months after the Ubuntu 22.04 release. We’ve learned a lot since then and significantly grown the partnership between Canonical and Microsoft. Starting with Ubuntu 24.04, Ubuntu feeds will be the official source of packages for .NET.

.NET installation docs have been updated to reflect the latest instructions.

Ubuntu 24.04 container images are already available, for .NET 8+. They include noble, noble-chiseled, and noble-chiseled-extra image flavors.

neofetch and dotnet logo on Ubuntu 24.04

Ubuntu LTS releases are always quite popular. We’re excited that .NET is part of Ubuntu 24.04 and expect a lot of .NET developers will start using these new packages and container images in the coming weeks and months.

Want to learn more? Sign up for Microsoft Build 2024, it’s free, and watch our session with experts from Canonical and Microsoft.


Installing .NET 8 on Ubuntu 24.04 is straightforward.

$ sudo apt update && sudo apt install -y dotnet-sdk-8.0
$ dotnet --version

Installing .NET 8 is the same as installing any other package available in Ubuntu. There are no extra feeds to configure.

.NET 6 and 7 are available in the Ubuntu .NET backports package repository (also maintained by Canonical).

Here’s how to install .NET 6 using the dotnet/backports repository.

$ sudo add-apt-repository ppa:dotnet/backports
$ sudo apt install -y dotnet-sdk-6.0
$ dotnet --version

.NET 7 can be installed using the same pattern, although the dotnet/backports repository only needs to be registered once.

In all cases, the gestures are simpler than registering the packages.microsoft.com feed.


  • Install the software-properties-common package if add-apt-repository isn’t found.
  • The installation may also install tzdata, which has an interactive install.


The noble container experience is much the same as jammy. The new images support non-root, chiseled, and are globalization-ready.

The upgrade is quite straightforward. I can demonstrate with a sample Dockerfile targeting `jammy-chiseled.

$ grep jammy Dockerfile.chiseled
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:8.0-jammy AS build
FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled
$ sed -i "s/jammy/noble/g" Dockerfile.chiseled
$ grep noble Dockerfile.chiseled
FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:8.0-noble AS build
FROM mcr.microsoft.com/dotnet/aspnet:8.0-noble-chiseled

The images are currently in nightly.

sed -i "s;/dotnet/;/dotnet/nightly/;g" Dockerfile.chiseled

We can now build and run a container.

$ docker build --pull -t aspnetapp -f Dockerfile.chiseled .
$ docker run --rm -it -p 8000:8080 -m 50mb --cpus .5 aspnetapp
warn: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
      Storing keys in a directory '/home/app/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed. For more information, go to https://aka.ms/aspnet/dataprotectionwarning
warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
      No XML encryptor configured. Key {6326de0e-7eab-412d-9d06-eb0d019e5590} may be persisted to storage in unencrypted form.
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://[::]:8080

ASP.NET Core container image using `noble-chiseled`

That was a quick upgrade.

I did a quick size comparison, before and after. They are about the same.

$ docker images aspnetapp
REPOSITORY   TAG              IMAGE ID       CREATED          SIZE
aspnetapp    jammy-chiseled   d938d8ee1104   51 seconds ago   118MB
aspnetapp    noble-chiseled   e59689894c68   35 minutes ago   119MB

Security and support

Microsoft and Canonical are collaborating on servicing and support. To that end, Microsoft gives security and functional fixes (via a private channel) to Canonical ahead of Patch Tuesday releases, with time for building and testing. We do the same thing with Red Hat. It’s our goal that .NET fixes are available everywhere, simultaneously.

The official source of .NET packages will be via Ubuntu feeds, as already stated. That raises the question of support. You can file issues for .NET on the dotnet8 launchpad or in the appropriate dotnet repo. If there is any ambiguity on which organization should resolve the issue, we’ll handle that through our partnership.

Build 2024 Talk

Title: Seamlessly leverage .NET on Ubuntu from development to deployment

Description: Discover how Canonical and Microsoft streamline .NET development on Ubuntu. Learn about .NET packages in latest Ubuntu releases, the evolution of .NET containers, and the benefits of ultra-secure, optimized chiseled Ubuntu containers.


We’re excited for .NET to be so well integrated in Ubuntu or for the strong support of our friends at Canonical. We’ll continue to find and explore new ways to improve the experience of .NET on Ubuntu.


Leave a comment

    • Richard LanderMicrosoft employee 0

      They are only in nightly currently. That should change next month.


      $ docker run mcr.microsoft.com/dotnet/nightly/aspnet:8.0-noble dotnet --info | head -n 5
        Version:      8.0.4
        Architecture: x64
        Commit:       2d7eea2529

      Separately, the Docker Hub pages are not updating correctly at the moment. That page would lead you to believe that we haven’t updated images since March, which is very much not true.

      • Jiří Zídek 0

        Right. DockerHub lags a bit. I used to use it, because their page is way more well-arranged.

  • Mystery Man 0

    Congratulations to our friends at Canonical. I’d say it’s an auspicious day, but it is more noble than that!

    That’s one significant statement. Nobody from Microsoft has ever declared the release day of Windows 11 an auspicious day. Then again, Windows 11 deliberately doesn’t bundle .NET 8, 7, 6, or 5.

  • Sérgio Terenas 1

    Richard, is there any plan to have this easy way to install/update NET8+ on Raspberry Pis? 🙏

  • Craig Treasure 0

    Very cool to have this available on day 0! Now, if only PowerShell would follow suit…

  • David Cuccia 0

    Richard, this is great, thank you for your team’s work. What would be even more great is MAUI support. Please?

    • Richard LanderMicrosoft employee 0

      The MAUI team (as you likely guessed) isn’t currently targeting Linux in their plans. As a result, it isn’t part of our partnership with Canonical.

  • Mark Adamson 0

    Nice work. As I understand it from a previous post, ubuntu will only ever have 8.1## SDK releases, not 8.2##, 8.3## releases. Where does this leave the default GitHub Actions Ubuntu runners? Will they continue to have the later SDKs as they do at present, e.g.:


    I realise it’s not directly related, but only asking since GitHub is Microsoft owned now.

    • Richard LanderMicrosoft employee 1

      That’s a great question. The GitHub runners install the Microsoft builds via tarballs so nothing will change.

  • Tadeas Lejsek 0

    Thank you for the blog post, I have two questions to it:

    1) Since ubuntu noble contains only the 8.0.1XX band of the dotnet SDK in its repositories and microsoft PPA won’t be available, how should developers install the latest version of the SDK? Some tooling requires newer bands of the SDK to work (VS Code extensions etc.).

    2) Previous dotnet LTS versions used to be supported for cca 3 years, but dotnet 8 on ubuntu will be supported much longer. Will this extended support be accessible elsewhere as well (container images, other platforms)?

    • Richard LanderMicrosoft employee 0

      Great topics.

      We’ve never had much discipline on maintaining a limited difference between the .1xx and higher bands. We’re going to try to do better on that front and we ask users to keep us honest on that (by filing issues).


      When folks need or want .2xx+ on Ubuntu 24.04, they will need to manually install it, either with the install script or curl/tar. This is similar to using/testing previews for a higher major version. I often go back and forth between versions. My trick is to install the non-default version in ~/dotnet and then update with the path with export PATH=/home/rich/dotnet:$PATH. That works well for me and will not work well in other scenarios. I get it. Variations of that approach can work for other scenarios.


      Microsoft-produced assets will only be available until the EOL date for a given release. Canonical produces container images and I expect that they will be available longer. You can validate that with them. It would be good for them to hear about expected needs and to get a sense of the demand.


      • Tadeas Lejsek 0

        Thank you for your response. I was a bit afraid you’ll say that: “When folks need or want .2xx+ on Ubuntu 24.04, they will need to manually install it”. It’d be great to have an automated out-of-the-box way to stay on the latest dotnet sdk version on ubuntu noble (a.k.a apt update && apt upgrade). Anyway, does the install script support an upgrade operation (if one installs to the same location)? Or does one first have to uninstall the old version?

        • Richard LanderMicrosoft employee 0

          I understand. Our big problem is that we couldn’t figure out a good way to offer a “competing” feed to what was in Ubuntu. The current model with packages.microsoft.com has been proven to not work. We are very thankful and appreciative to our friends at Canonical for offering .NET packages. We decided that it was in everyone’s best interests (in aggregate) if we stopped publishing our images (starting with Noble). It has a “con”, as you raise, however, we believe that the existing model was even worse (including a high support cost for us when customer environments broke).

          I described the thinking in more detail at https://github.com/dotnet/core/discussions/9258.

          I asked someone to provide more insight on the behavior of the install script.

          • Chet HuskMicrosoft employee 0

            Hi Tadeas – unfortunately the install scripts don’t have an upgrade mode today. They are only intended for acquiring SDKs and Runtimes – though you can use them multiple times to install different SDKs to the same location. To cover the update scenario, today you can delete the entire directory and download the SDK(s) you need – I realize this isn’t an integrated solution.

            I do agree that this change puts more pressure on the need to have an integrated way to manage SDK installations for developers – please consider leaving feedback on https://github.com/dotnet/sdk/issues/7549 to help us track interest in developing this capability.

Feedback usabilla icon