3 ms·

IME (and I worked at Microsoft previously), Nuget and MSBuild have decided that application developers should have full control of their dependencies and that s

IME (and I worked at Microsoft previously), Nuget and MSBuild have decided that application developers should have full control of their dependencies and that system administrators can override these things but not easily. I understand that distro-level package manager want to make it possible to upgrade a system library for all applications, but the .NET world isn’t going in that direction (yes yes I know about the GAC et al. but that’s more trouble than it’s worth) The implicitly assumption in the .NET choice is that dependencies may not be backwards compatible, so compile against a specific version and go ahead and ship that assembly in your self-contained deployment. Yes your packages are bigger, but disk space and bandwidth are cheaper than developer time and support costs.

pxc 4y ago
Application developers can still pin their in-ecosystem library dependencies to exact versions and have downstream, distro-level package managers respect that while building everything from source and making the system package manager aware of all of those library versions in more or less the usual way. (That's how building Rust and Go applications already works on NixOS, for example.) That's why I say it's largely a solved problem for language ecosystems that tick a few basic boxes. Can't Nuget and MSBuild support this? Can they not dump lockfiles like common build tools for Rust, Go, Javascript, Haskell, Python, Nim, PHP, etc., do? Is there a general problem (like there is with Java) where actually building from source is so difficult that it is rarely done? Anyway there's already a suite of Linux packaging options built around the kind of app distribution model Microsoft expects, and Canonical even has one of their own! I don't see why they wouldn't support distributing .NET applications as Snaps, or maybe even automating the creation of Snap packages for .NET applications.
- guhidalg 4y ago
  There is no immediate problem with building from source, there simply isn't much of a benefit to doing so. An assembly compiled with different optimizing C# compilers will be virtually identical assuming the source files are identical. 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 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.
  - pxc 4y ago
    Hm. Thanks for this and previous answers. > 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.
    - guhidalg 4y ago
      Yes I think it is possible to ship dotnet applications and packages as apt or other image formats. What I would do is to put the Nuget package inside the deb package, extract it into the local Nuget cache, and then let Nuget discover it as if it had downloaded it.

pxc 4y ago

Application developers can still pin their in-ecosystem library dependencies to exact versions and have downstream, distro-level package managers respect that while building everything from source and making the system package manager aware of all of those library versions in more or less the usual way. (That's how building Rust and Go applications already works on NixOS, for example.) That's why I say it's largely a solved problem for language ecosystems that tick a few basic boxes. Can't Nuget and MSBuild support this? Can they not dump lockfiles like common build tools for Rust, Go, Javascript, Haskell, Python, Nim, PHP, etc., do? Is there a general problem (like there is with Java) where actually building from source is so difficult that it is rarely done? Anyway there's already a suite of Linux packaging options built around the kind of app distribution model Microsoft expects, and Canonical even has one of their own! I don't see why they wouldn't support distributing .NET applications as Snaps, or maybe even automating the creation of Snap packages for .NET applications.

guhidalg 4y ago
There is no immediate problem with building from source, there simply isn't much of a benefit to doing so. An assembly compiled with different optimizing C# compilers will be virtually identical assuming the source files are identical. 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 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.
- pxc 4y ago
  Hm. Thanks for this and previous answers. > 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.
  - guhidalg 4y ago
    Yes I think it is possible to ship dotnet applications and packages as apt or other image formats. What I would do is to put the Nuget package inside the deb package, extract it into the local Nuget cache, and then let Nuget discover it as if it had downloaded it.