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.