> I can think of a reason not to compile from source: it's essentially statically linking code into your assembly which can be huge problem for middleware packages that want to override the specific version you depend on. This is very common with the JSON serialization library, which is highly backwards compatible.

I think if .NET were integrated into Linux package management systems in the 'organic' way, 'building from source' here would still be 'building from source with the assistance of the distro package management tooling', which would mean that you would get intermediate build artifacts for all the deps, recursively.

If you have to do that manually, it would suck. But when automated tools can generate those packages, it works relatively nicely.

> I think historically in the .NET world, package consumers have expected pre-compiled assemblies and not source code and so that's what the ecosystem has developed around.

Yeah, and I can see how distros burning their own compute bandwidth building the same binaries into their own artifact repository systems instead of using Nuget might seem like more of a religious rite than a purposeful task.

But I think the ability to uniformly inspect and update the software on the system is a big deal when it comes to Linux distros, as is the ability to add source patches, especially for backwards compatibility or security fixes, to most people involved in putting distros together.

I don't know if Canonical is up for it with Ubuntu, but it does sound like building dotnet applications in a way that is conventional for Linux distros is certainly possible. Alternatively, something like AppImage, Flatpak, or Snap seems like a natural fit for distributing apps with libraries shipped directly by the publisher that Ubuntu or other distros could use to include .NET applications.