Correctly configuring .NET SDK(s) in a Linux environment

[richlander]

We need to get clear instructions and some testing in place for correctly installing one or more .NET SDK versions on Linux, with a bias to Ubuntu. We had some reports of this not going well. We're going to use this issue as the official tracking issue.

We need the following:

• Clear instructions, targeting a variety of distros/versions.
• Validate that various environments work correctly, such as: raw metal, GitHub runners, WSL, Docker, dev containers.
• Publish the final experience as a blog post

We had discussed this recently. The reports now provide "accelerated motivation".

Instructions (growing list over time):

• Install .NET on Ubuntu 22.04
• Install .NET on Ubuntu 24.04

Relevant announcements:

• .NET 9 Package Publishing core#9556
• .NET Packages for Ubuntu 24.04 core#9258

[richlander]

Hey @pinkfloydx33 -- Can you share your package sources? I'd like to understand if you have any Microsoft ones.

[huoyaoyuan]

A question maybe related: is there effort/plan to get dotnet into Debian source? Would this benefit the downstreams of Debian, or if the deb package for Debian is enough?

[richlander]

Great question. Yes, Debian providing .NET packages would be great. If that happened, we'd stop publishing Debian packages, per our policy.

We have separately talked to Debian maintainers at Microsoft and Canonical and also to one other Debian-affiliated person. In all cases, the projects started and didn't finish. I don't recall the details. My understanding is that our bootstrapping requirements are a significant friction for Debian. They are significant friction everywhere, but more so w/rt Debian policies. I believe that there may have been some licensing issues, but I assume those are easier to resolve (since we have moved everything to MIT for Linux).

A quick bootstrapping definition ... When someone wants to sourcebuild .NET 10 Preview 1, then need to acquire the .NET 10 Preview 1 SDK from Microsoft and then do a two-phase build. "One does not simply" using the .NET 9 SDK to build .NET 10. As soon as .NET 10 starts, we start using new features everywhere. That's the reason. We talked about not doing that, but we really like using new features right away as a validation and performance-benefiting tool.

We do not plan to take this project on. We're best suited to being a broad enabler of many things and to do the best job we can providing the downstream Microsoft builds.

[huoyaoyuan]

My understanding is that our bootstrapping requirements are a significant friction for Debian. They are significant friction everywhere, but more so w/rt Debian policies.

I've heard similar concern from Gentoo user. There are difficulty/failure when trying to build 2xx/3xx SDK brands. I also plan to do a non-cross compile build for LoongArch, for which I designed some hacks but haven't verified.

When someone wants to sourcebuild .NET 10 Preview 1, then need to acquire the .NET 10 Preview 1 SDK from Microsoft and then do a two-phase build. "One does not simply" using the .NET 9 SDK to build .NET 10. As soon as .NET 10 starts, we start using new features everywhere.

For my expectation, one should be able to build .NET 10 Preview 1 with "any distribution" of .NET 9 SDK, then use any 10 Preview 1 to build 10 Preview 2, etc. This gives a self-bootstrap experience with still allowing us to adopt new features in monthly pace.
For now in theory, one should be able to self-bootstrap if they do rolling build for every nightly version, right?

We're best suited to being a broad enabler of many things and to do the best job we can providing the downstream Microsoft builds.

I believe we are aware of the more benefit, for example enabling dotnet-based applications to be adopted into their source tree. For smallish platforms that Microsoft build doesn't cover, improving source-build without cross compilation can improve their experience. There is also a non-solid concept about "trust to Microsoft programming platform".

Anyway, I understand the challenges with our current practices and more. Hopefully we can improve step-by-step in the future, and finally achieve all of these.

[richlander]

I agree that a focus on both the long-term goals and the path of small steps to get there is a winning combination.

You can also look to the past to validate these ideas, like for example if latest .NET 8 SDK can build .NET 9 Preview 1 and determine what the problems are.

The 2xx/3xx/4xx bands are quite a challenge. There are really there for Visual Studio but complicate many things. Windows users using Linux are frequently unhappy when the latest features bands are not available in Ubuntu. For clarity, we have not (AFAIK) provided anything but .1xx sources via the source build path. This will change with .NET 10 and Unified Build / VMR. All feature bands will be equally supported. It's possible that will help.

[tmds]

For my expectation, one should be able to build .NET 10 Preview 1 with "any distribution" of .NET 9 SDK

This hasn't been a goal and I am not aware that it is one. It isn't until the later previews that the builds are capable of being built with the previous preview.

This gives the flexibility of breaking changes between early previews which would otherwise be expected to maintain this backwards compatibility. The (acceptable) drawback is that maintainers require a current SDK to build those early previews (provided by Microsoft or cross-compiled).

one should be able to self-bootstrap if they do rolling build for every nightly version, right?

Yes, you can build the main branch using an SDK built from the main branch.

improving source-build without cross compilation can improve their experience

Back in the old days, there was a script (dotnet/source-build#2930 (comment)) but that approach has been abandoned in favor of cross compilation with the vmr. That is what we're doing for bootstrapping s390x and ppc64le builds.

We need to get clear instructions and some testing in place for correctly installing one or more .NET SDK versions on Linux

In .NET distribution packaging we outlined how .NET should be split across distribution packages to enable a common UX across Linux distributions. The described packaging intends to enable side-by-side installation of several .NET versions.

[pinkfloydx33]

Hey @richlander I figured it out. Another stage in the packer run was adding the Microsoft repository as it's needed for other things (like the azure cli and powershell). I don't know how I missed this.

I was able to resolve this by deprioritizing the Microsoft repository (wrapping the installation of dotnet only) with a negative priority. I've successfully got all three SDKS installed now.

I was clued in by your example yesterday. The packer builds install one sdk at a time. I changed it to install all three at once and got errors about conflicting requirements. The conflict was coming from dotnet-host and some netstandard targeting pack which was weird, as rdepends wasn't showing anything for them. After that I did a deep dive and found the other registration of the msft repository. I should've done that first and I apologize for all the noise that resulted from it.

For reference we use a heavily modified/slimmed down fork of https://github.com/actions/runner-images/tree/main/images/ubuntu. I'm pretty sure they are going to hit a similar issue on the dotnet installs since they register the same repos... unless they skip the apt package and only install from archive.

When we added net8 it was literally a one line change, adding it to the list of apt packages to install, and it just worked. That was my expectation this time around, and I admit that it was a bit naive of me!

I guess the only unfortunate side effect of using the Canonical repo is that they use the .100 band of the SDK, which won't necessarily match our local setups. Or am I misunderstanding something about that?

This all still does not explain how I was able to install dotnet-sdk-9.0 from the Microsoft repo on 11/13! Could that have just been some fluke around the GA of 9?

I've got scheduled work to get our agent images upgraded to a more recent version of Ubuntu, but it's on the backburner as there's 10 billion other things I need to do and there's just one of me. 😄

I appreciate all of your help and again, I really do apologize for not doing a better investigation before posting.

Edit: another thing I noticed is that the 8 runtime/sdk from this feed is behind a version. I'm not sure how long it takes to get 8.0.11 in there. I had to pin some dotnet global tools to older versions because they were expecting 8.0.11 but only found 8.0.10. For example I hit this with sql package. Any idea how long it typically takes for these to be updated in the Canonical feed?

[richlander]

I'm going to look at the runners next. They will be an excellent central spot to correctly configure an environment. I think the best idea from the runners is to install the .NET tar balls. This is the same thing Actions does.

[taspeotis]

I came here from #44901

My ambition was to create a Docker image based on the .NET 9 SDK image (mcr.microsoft.com/dotnet/sdk:9.0) but with the .NET 8 runtime installed so that dotnet build/package/test can build/package/test our .NET 8 and .NET 9 projects.

(Strictly speaking only test seems to need the 8 runtime.)

Anyway the 9.0 tag is based off Ubuntu 24 and if I follow the instructions to install the runtime here then I lose access to the .NET 9 SDK because the Canonical dotnet "wins".

Canonical dotnet can't see the .NET 9 SDK and the Microsoft dotnet can't see the .NET 8 runtime.

There is a warning about mixing package sources but also there is a warning that Microsoft doesn't publish for Ubuntu 24 so one might think the problem cannot occur: there is no Microsoft package source to fight with Canonical's package source.

But the problem still occurs here - the Docker image installs .NET from Microsoft's binaries for Ubuntu 24, and it doesn't play with the fork of dotnet that Canonical produce.

Please note this is feedback and maintaining the documentation on how to install .NET on various Windows/macOS/Linux operating systems is probably a thankless task. But it was a bit confusing to follow the "official" instructions on how to install the .NET 8 runtime on Ubuntu 24, and it doesn't do what I want using the official Microsoft .NET 9 SDK image based on Ubuntu 24.

[richlander]

Here's the approach I would use. It's simple and has good results. If you don't need aspnet, you can change the COPY line. This is just a pattern you can adapt to your scenario.

rich@mazama:~/dtest$ cat Dockerfile 
FROM mcr.microsoft.com/dotnet/sdk:9.0
COPY --from=mcr.microsoft.com/dotnet/aspnet:8.0 /usr/share/dotnet/shared /usr/share/dotnet/shared
rich@mazama:~/dtest$ docker build --pull -t two-runtimes .
[+] Building 0.3s (8/8) FINISHED                                 docker:default
 => => naming to docker.io/library/two-runtimes                            0.0s
rich@mazama:~/dtest$ docker run --rm two-runtimes dotnet --list-runtimes
Microsoft.AspNetCore.App 8.0.11 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.11 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

[taspeotis]

Thanks, that is straightforward.