3 ms·

I wonder if this opens the door for .NET applications to be included in Ubuntu? Neither this blog post nor Ubuntu’s [1] mention that as a possibility. Just thi

I wonder if this opens the door for .NET applications to be included in Ubuntu? Neither this blog post nor Ubuntu’s [1] mention that as a possibility. Just thinking from a Ubuntu package level, where libraries live in packages separate from executables, it might be possible to create library packages using the result of ‘dotnet store’. Then executable packages could reference them when running ‘dotnet publish’. [2] That way multiple executable packages could share common libraries. Replicating the packages of a language package manager (Nugget in this case) into a system package manager (apt in this case) is probably not fun. You will end up with dependency nightmares or one system package per version of Nugget package. So maybe it’s not worth doing. [1]: https://ubuntu.com/blog/install-dotnet-on-ubuntu https://ubuntu.com/blog/install-dotnet-on-ubuntu [2]: https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-store https://docs.microsoft.com/en-us/dotnet/core/deploying/runti...

jayd16 4y ago
Ironically, .NET is positioned to use a shared runtime but Linux has all the package manager tooling and Microsoft's never took off. The buggy nature of shared runtimes on Windows meant that the culture is to ship a full runtime with your .NET app. I'm not sure going back to shared runtime libs is worth the headache but I guess if you were really resource constrained but running .NET it would work for you.
guhidalg 4y ago
I don’t think it would be wise for apt to repackage or recreate Nuget functionality. The initial install of dotnet should be done by apt, the packages should be handled by Nuget.
- pxc 4y ago
  If you want to package an application which depends on a library, you have to package the library, too. This is the (pretty much sole) reason that distros package libraries. From a technical perspective it's pretty much a solved problem for any language ecosystem whose dependency management is reproducible, is uniform enough to support basic automation, and supports some measure of vendorization.
  - guhidalg 4y ago
    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.
WorldMaker 4y ago
Ubuntu briefly included Mono-based apps in the core distribution. Sadly the backlash controversy after that around the size of the Mono runtime (which wasn't much bigger than Python at the time, but got a bit of a "but we've already got Python, we don't need 2 Pythons" in response, and ahead of the whole python2/python3 split, hah) and the worse controversy about Microsoft-adjacent conspiracy theories did a lot of damage to the then-nascent world of Gtk+ based .NET apps in Linux and left some scars. The first part seems to add confidence that if the right apps/developers came along, Canonical themselves likely wouldn't have a problem putting them in the distribution. The second part would explain why there aren't just apps waiting in the wings for it and why "the community" (or at least certain vocal parts) may still not be as welcoming of .NET-based apps in the distribution this time around like it played out that previous time.
omajid 4y ago
Unfortunately, packaging applications built on .NET is still a challenge for any OS that wants to build everything from source and doesn't allow network access. Like you say, duplicating nuget into os-app-package-manager is challenging. Even side from the duplication, we need to bootstrap the ecosystem, in particular dealing with cyclic dependencies and version explosion as a result of all the different versions of all the dependencies that an average dotnet application needs. We are starting to work through it here: https://github.com/dotnet/source-build/discussions/2960 https://github.com/dotnet/source-build/discussions/2960. Any advice/tips/contributions would be welcome, I think.

jayd16 4y ago

Ironically, .NET is positioned to use a shared runtime but Linux has all the package manager tooling and Microsoft's never took off. The buggy nature of shared runtimes on Windows meant that the culture is to ship a full runtime with your .NET app. I'm not sure going back to shared runtime libs is worth the headache but I guess if you were really resource constrained but running .NET it would work for you.

guhidalg 4y ago

I don’t think it would be wise for apt to repackage or recreate Nuget functionality. The initial install of dotnet should be done by apt, the packages should be handled by Nuget.

pxc 4y ago
If you want to package an application which depends on a library, you have to package the library, too. This is the (pretty much sole) reason that distros package libraries. From a technical perspective it's pretty much a solved problem for any language ecosystem whose dependency management is reproducible, is uniform enough to support basic automation, and supports some measure of vendorization.
- guhidalg 4y ago
  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.

WorldMaker 4y ago

Ubuntu briefly included Mono-based apps in the core distribution. Sadly the backlash controversy after that around the size of the Mono runtime (which wasn't much bigger than Python at the time, but got a bit of a "but we've already got Python, we don't need 2 Pythons" in response, and ahead of the whole python2/python3 split, hah) and the worse controversy about Microsoft-adjacent conspiracy theories did a lot of damage to the then-nascent world of Gtk+ based .NET apps in Linux and left some scars. The first part seems to add confidence that if the right apps/developers came along, Canonical themselves likely wouldn't have a problem putting them in the distribution. The second part would explain why there aren't just apps waiting in the wings for it and why "the community" (or at least certain vocal parts) may still not be as welcoming of .NET-based apps in the distribution this time around like it played out that previous time.

omajid 4y ago

Unfortunately, packaging applications built on .NET is still a challenge for any OS that wants to build everything from source and doesn't allow network access. Like you say, duplicating nuget into os-app-package-manager is challenging. Even side from the duplication, we need to bootstrap the ecosystem, in particular dealing with cyclic dependencies and version explosion as a result of all the different versions of all the dependencies that an average dotnet application needs. We are starting to work through it here: https://github.com/dotnet/source-build/discussions/2960 https://github.com/dotnet/source-build/discussions/2960. Any advice/tips/contributions would be welcome, I think.