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.
Note: This announcement is targeted at Ubuntu 24.04, however, some of the details apply to Ubuntu 22.04. For example, Canonical only publishes .1xx release on Ubuntu 22.04 and 24.04.
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.
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:
Implications for Ubuntu usersMicrosoft will only publish packages for distros where .NET packages are not included in the distro archive.
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.
Note: The base challenge is that we (Microsoft) only make it practical for distros to build the .1xx band. We have done this for complexity/cost reasons due to the way our build system works. That is changing with .NET 10 with our Unified Build project. It will now be practical for distros to build previews and higher feature bands. That's partially evident with Leveling up Ubuntu for Developers: .NET Edition. We expect that some distros will switch to the higher feature band, some will ship multiple, and others will stick the .1xx policy due to compatibility concerns with the higher feature bands. Incidentally, the original name of Unified Build was "Salmon.Net". The intent was to make it easier for distros to swim upstream.
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
Canonical is in the process of taking over the Snap package from Microsoft. It will switch to installing Canonical-built .NET packages.
Commitment to UbuntuMicrosoft 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 packagesWe'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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4