.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?

[baronfel]

Yes, I can do so here. Some caveats:

• THIS IS A HACK
• I may not have all of the required extensibility points down, this is just what I had to do to enable the Android workload, and it may work for many of the other workloads

There are two main steps

• update the on-disk, user-local SDK layout with an extracted workload manifest for the workload you'd like to install
• update the KnownWorkloadManifests.txt file in the SDK to recognize the workload you'd like to install

Extracting the workload manifest on-disk

If you look in an SDK installation, you'll see an sdk-manifests directory with the following structure. For distro-based installs you will have this in your global SDK installation location, but we will be modifying the user-local install location, which by default is ~/.dotnet/sdk-manifests. If this doesn't exist, create it now.

* sdk-manifests
  * <SDK Feature Band>
    * <Workload Id>
      * <Workload Manifest package version>
        * <extracted targets of the workload manifest nuget package>

Now, for the workload you want to enable, you'll need to know the package id of the workload manifest for that workload. In this case I want the android workload, which matches the Microsoft.NET.Sdk.Android.Manifest NuGet package. These manifest packages have names in the form <Workload Manifest Id>-<SDK Feature Band>, so since I'm using the 8.0.100 SDK here I'm going to look for the 8.0.100 package. Then, I'm going to download the latest version of this package and note the version number.

From here, go to your sdk-manifests directory and create the directory structure mentioned above. For me at time of writing this is the following

* sdk-manifests
  * microsoft.net.sdk.android
    * 34.0.95

Finally, extract the contents of the NuGet package's data folder (which for this workload is just the WorkloadManifest.json and WorkloadManifest.targets, but for other workloads may contain other data) to the versioned folder.

Update the SDK known manifests

Open the file KnownWorkloadManifests.txt from the versioned-SDK subfolder you care about (e.g. I'm on 8.0.105, so my final path to this file was /usr/lib/dotnet/sdk/8.0.105/KnownWorkloadManifests.txt) and add the workload id to this file.

Next steps

Once you do these two steps, workload installation should work for you. The longer-term work the MAUI team will do to onboard the manifest generation to source build should effectively do these steps for you, so at some point in the future you may need to delete some or all of your user-local sdk-manifests directory. I'm not certain of the impact there.

[PathogenDavid]

This has led to an unfortunate situation where net48/net8.0-windows/etc apps can no longer be built on Ubuntu because the Ubuntu packages lack the Microsoft.NET.Sdk.WindowsDesktop SDK folder. (This folder has always been present in Microsoft distributions as far as I'm aware.)

This might not be so bad (installing manually is annoying but not the end of the world) except that you get a pretty vague error without a clear resolution:

/usr/lib/dotnet/sdk/8.0.107/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(1355,3): error MSB4019: The imported project "/usr/lib/dotnet/sdk/8.0.107/Sdks/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.targets" was not found. Confirm that the expression in the Import declaration ";/usr/lib/dotnet/sdk/8.0.107/Sdks/Microsoft.NET.Sdk/targets/../../Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.targets" is correct, and that the file exists on disk.

It'd help a lot if the SDK printed a more helpful error message here at the very least.

---

It would also be nice if there was a notice added to the Ubuntu installation documentation stating that Microsoft no longer provides packages starting with Ubuntu 24.04 (maybe with a link to this issue.) It's mentioned elsewhere on that page but it's easy to miss.

[baronfel]

Thanks for following up - do you have some quick instructions I could follow to repro your failure? I'd like to repro it myself and dig into what parts we're missing to make this light up. We should make this work so that Linux users don't have a take-back in terms of functionality.

[PathogenDavid]

I will double-check and write up a more detailed repro using a fresh Ubuntu VM when I get a chance, but here is the minimal repro I was using to test while I was investigating things: WindowsDotNetOnLinux.

Other than swapping the TargetFramework in the csproj between net48 and net8.0-windows, I'm 99% sure the repro project is unchanged from before I solved the problem since the workaround was just manually installing the SDK.

I was testing on an extremely vanilla Ubuntu Desktop 24.04 Hyper-V VM that was created yesterday specifically for debugging an unrelated Linux-only issue for work. (I needed a completely fresh environment and just defaulted to the latest version.)

Should be as simple as running dotnet build in the repro root and either:

• With the dotnet-sdk-8.0 package installed from Ubuntu: It will fail with the MSB4019 error above.
• With a manual installation created using dotnet-install.sh: It builds just fine.

[richlander]

I think source build is a good and interesting path. However, it isn't clear to me that it is the primary path. Targeting packs are special and it may not be reasonable to expect that all targeting packs are available from all distro archives. I propose that targeting packs should always be available from Microsoft via Nuget.

I believe that some scenarios require more than a reference assemblies (for example, a camp compiler). This was apparently already working via PMC so I assume that key scenarios are already enabled.

[baronfel]

This is really interesting. It looks like for Windows Desktop we don't do the pluggable mechanism for WindowsDesktop like we do for other on-demand bits of functionality like AOT compilation or SingleFile compilation. The normal pattern is that framework references and other tools can be located in a number of locations:

• in the DOTNETSDK_WORKLOAD_PACK_ROOTS directory,
• in the user's HOME/.dotnet/packs directory,
• colocated with the SDK install root in the packs directory, and finally
• resolved from NuGet

This allows for different deployments of the SDK to still provide the same dependencies and logic, just with varying amounts of pre-packaging.

The WindowsDesktop bits do not appear to follow this pattern. While we do provide the packages for the reference assemblies and win0x86, win-x64, and win-arm64 runtime implementations, the SDK hard-codes an expectation that the WindowsDesktop targets will be colocated in the SDK layout here. If we do expect users to be able to do some amount of compilation for the WindowsDesktop runtime on other platforms, then we will need to do some amount of work to make the WindowsDesktop feature set behave like our other FrameworkReferences.

cc @marcpopMSFT @dsplaisted

Attached is a binlog for anyone that would like to look at the problem.
dotnet.zip

[richlander]

Thanks for doing that legwork. That is indeed what I was getting at but didn't have the context to describe.

In an ideal world, a distro (or anyone) could provide a fairly minimal build of the SDK and many things could be acquired on-demand. With source build, we often think of license and bootstrap/reproducibility boundaries and such things. That's all good, but there are many scenarios where those topics won't matter.

[lonix1]

For many users, this policy won't change much. ... 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.

I just upgraded to Ubuntu 24.04 and all my stuff stopped working. After much invstigation I realised that my code was expecting SDK 8.0.401 (released a month and a half ago), but the package manager only offers 8.0.108.

So although the problem that led to this decision is real and understandable, the solution is not ideal.

The Ubuntu package repo is notorious (for good reason) for having older versions. I generally like that, but not for work-related packages (i.e. coding tools), for which I want the latest bugfixes.