.NET Packages for Ubuntu 24.04

[richlander]

The release of Ubuntu 24.04 is just around the corner. Canonical-produced .NET 6, 7, and 8 packages will be available on day one, for "Noble Numbat". Microsoft will not be publishing .NET packages to the 24.04 feed at packages.microsoft.com.

Context

We have been working closely with Canonical on .NET packages in Ubuntu for a few years now. We announced .NET 6 in Ubuntu 22.04 almost two years ago. The Canonical packages are kept up to date and compiled from upstream source.

The initial rollout of .NET 6 in Ubuntu was unexpectedly challenging. We didn't realize the degree to which packages from two publishers with the same package names would conflict. In retrospect, this should have been obvious and we should have done a better job preparing the community.

Sadly, this problem repeated itself when Canonical published .NET 8 packages after Microsoft packages were already available.

Dual-publishing packages like this is inherently challenging. In any case, we're not doing it well, and we have not identified an approach that we think would make it work a lot better.

One of the challenges is that packages.microsoft.com is a generic service (for Microsoft). For example, the 22.04 feed contains multiple products. Users that want to register the feed to acquire one Microsoft product are registered for all products on that feed. However, a correctly working .NET installation can get damaged due to registering the Microsoft feed to install PowerShell, for example.

Policy

We are very appreciative that .NET is now built and included by multiple Linux distributions. A lot of collective effort has gone into dotnet/dotnet and dotnet/source-build repos. The fact that multiple distros now rely on and contribute to these "source build" efforts is evidence of a certain level of acceptance in these distro communities. We're very thankful for that.

We've decided on the following policy:

Microsoft will only publish packages for distros where .NET packages are not included in the distro archive.

Implications for Ubuntu users

For many users, this policy won't change much. .NET will be available in Ubuntu and many users will just install and use it. In the past, .NET versions were (somewhat) slow to show up in the Ubuntu archive. We expect that new versions will show up more quickly at this point. The fact that .NET versions will be available for Ubuntu 24.04 on day one is evidence of that.

For other users, this will be more of a challenge.

The first challenge is that the SDK has a concept of feature bands. Most distros, including Ubuntu, stick to the .1xx feature band for the lifetime of a major .NET version. They make this choice because .1xx is (effectively) the "compatibility band". Higher bands can have breaking changes.

This means there will no longer be packages available for .2xx and later feature bands. Such packages have been exclusively available from Microsoft.

This situation is primarily a problem for users who write code in Visual Studio (which install the later feature bands) on Windows and then build their code on Linux (with a .1xx feature band SDK).

If users see an incompatibility between .1xx and higher feature bands, we ask that you please report it in the dotnet/sdk repo.

Note: The feature band concept is an unfortuante complexity. It was invented due to Visual Studio and the .NET SDK shipping a few of the same components (Roslyn, MSbuild, NuGet) and Visual Studio having a different compatibility bar. We would prefer not to have feature bands, but have been unable to satisfy product and compatibility needs otherwise.

Separately, some users may prefer Microsoft-built binaries. We're not in a position to tell users who to trust. However, it should be noted that Microsoft gives Canonical CVE (source) patches ahead of embargo so that they can publish patched binaries to Ubuntu feeds at the same time as Microsoft.

Users that require higher feature bands or Microsoft-built binaries can install them via the install script or download .tar.gz archives. The containers we publish also include the highest feature band.

$ docker run --rm mcr.microsoft.com/dotnet/sdk:8.0 dotnet --version
8.0.203

Snap package

Canonical is in the process of taking over the Snap package from Microsoft. It will switch to installing Canonical-built .NET packages.

Commitment to Ubuntu

Microsoft is committed to Ubuntu being a first-class environment for .NET developers and users. Canonical and Microsoft continue to work closely together towards that goal.

For example, we recently announced Chiseled containers as a joint project.

Improve Debian packages

We've been talking about what to invest in next. Debian (upstream of Ubuntu) does not have .NET packages. We will continue producing Debian x64 packages (per our policy) and are considering also producing Arm64 packages.

[cspwizard]

Hi!

Any updates on the issue? dotnet is still missing in packages.microsoft.com/ubuntu/24.04

sudo nano /etc/apt/sources.list.d/microsoft-prod.list
deb [arch=amd64,arm64,armhf signed-by=/usr/share/keyrings/microsoft-prod.gpg] https://packages.microsoft.com/ubuntu/24.04/prod noble main

sudo apt install dotnet-sdk-8.0
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package dotnet-sdk-8.0 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'dotnet-sdk-8.0' has no installation candidate

[richlander]

Microsoft will not be publishing packages. The statement above communicates that.

[atauenis]

@cspwizard , it's not necessary to use packages.microsoft.com for dotnet on Ubuntu. 8.0 is available at default Ubuntu repo, and 6.0/7.0 at backports PPA: https://learn.microsoft.com/en-us/dotnet/core/install/linux-ubuntu#supported-distributions

[richlander]

Correct. This context is also covered in my recent post at https://devblogs.microsoft.com/dotnet/whats-new-for-dotnet-in-ubuntu-2404/

[klemmchr]

Microsoft will only publish packages for distros where .NET packages are not included in the distro archive.

This decision has some implications. Currently not all workloads are supported for distro build SDK versions. This is especially true for MAUI workloads, the progress on that is tracked in dotnet/source-build#3242

As a result it is impossible to build MAUI application on any distro where only the distro build SDK versions are supported. The only workaround is to install .NET manually using the installer script or by downloading manually. It will also occur on distros where Microsoft still publishes the SDK using the Microsoft feed if you choose to use the recommended and most convenient installation method of using distro provided SDKs. A full description of this issue can be found in dotnet/sdk#41123

This behavior is not documented anywhere. Furthermore, you will be presented with an error that is completely intransparent about this limitation

Workload ID maui-android is not recognized.

I see two options to mitigate this issue:

• Publish Microsoft packages for distros where .NET packages are included (in short: abandon the policy described here)
• Speed up the work in Pull in MAUI repo(s) in order to source-build MAUI manifest nupkgs source-build#3242

The issue has no progress for almost a year now.

There are other users having the same problem:

• Workload ID maui-android is not recognized sdk#38171
• Not able to install MAUI on ArchLinux system sdk#40576
• Default xplat project cannot be built when .net8.0 is installed on linux (NETSDK1139: target platform 'android' is not recognized). AvaloniaUI/Avalonia#14897

According to dotnet/source-build#3242 (comment) this does also affect android and macos workloads, apart from the MAUI workloads.

[richlander]

@baronfel @MichaelSimons Do you have thoughts on these problems? As suggested, the error is not very helpful and seems like a place to start. I'm sure docs places a role here, too.

[baronfel]

The only real solution here is to speed up the source-build work for MAUI IMO. I've contacted the MAUI team this week and they are convinced of the urgency of the work.

[MichaelSimons]

@baronfel - IIRC you mentioned there was a way to get the workload installed. Is it worth sharing those steps to unblock those willing to use them?