5 ms·

I really like C# as a language, but as a Linux programmer, I found it difficult to install the dotnet sdk without the root permission. With that barrier, I can'

I really like C# as a language, but as a Linux programmer, I found it difficult to install the dotnet sdk without the root permission. With that barrier, I can't recommend C# over Java, D or Go which are much easier to install.

cebert 5y ago
You don’t need to install the SDK to run a dotnet core app. They can ship what’s required to run and there’s even single executable options now as well.
- spaetzleesser 5y ago
  One caveat: If you ship a self contained app you often end up with 200MB of assemblies to ship. and the single file executables tend to load very slowly. It's basically an archive that first gets extracted and then executed. I had to give that up with a recent app because it was just too slow.
  - kqr 5y ago
    Yes, this deployment option makes tradeoffs that are clearly more in line with the use case of pushing out long-running server applications to machines with minimal configuration, rather than for desktop user applications.
    - spaetzleesser 5y ago
      That’s my impression too. Seems these days in general desktop applications are more of an afterthought in the .NET world and most new features are built mainly for server stuff.
  - GordonS 5y ago
    This hasn't actually been the case since dotnet Core 2. Since dotnet Core 3, you can use assembly trimming to remove unused assemblies. That results in a package of around 10MB for a Hello World app, or more like 40-70MB for large, real-world apps. From dotnet 5 there is also member trimming, which will trim unused parts of assemblies, which will further reduce the size. I haven't used this yet, but Microsoft claim it can result in packages 5x smaller than with assembly trimming, e.g. only 2MB for a Hello World app. There is also AOT compilation, but I wouldn't hold my breath on seeing that become production-ready any time soon (Microsoft have been hyping it and saying it's "coming soon" for 10 years or so).
    - Measter 5y ago
      I just tried it on a small project of mine. It's 955 lines of C#[0], 6 dependencies, already configured for publishing a single file, self contained, for win-x64, ready to run. I built in release mode with publish trimmed, and trim mode set to link. The final size of the binary is 24.6 MB (not counting CLR DLLs), with a build time of 23.2[1] seconds. I also have a Rust version of the project. 710 lines of Rust[0], 128 total dependencies in the tree, building in release mode with the MSVC Windows compiler. Final size of the binary is 2.29 MB, build time of 22.2[1] seconds. Things are not great when your build times rival Rust's, and the output is slower and an order of magnitude bigger. [0] Note that the C# version does have more robust handling when writing its output file than the Rust version, which adds couple dozen lines. Also the style conventions for brackets puts opening brackets on a new line for C#, the same line for Rust. [1] Measured with hyperfine configured to run "dotnet clean -c Release" and "cargo clean" before each run.
      - e12e 5y ago
        > not counting CLR DLLs Why would you exclude those in this comparison - they're already (guaranteed to be) installed on your windows targets? How about linux/Mac targets? I think 20-30MB is quite good - puts it in the ballbark of golang. 2MB+ for rust actually sounds a bit big -that's stripped?
        Measter 5y ago
        > > not counting CLR DLLs > Why would you exclude those in this comparison - they're already (guaranteed to be) installed on your windows targets? Note that this is a stand-alone build; it doesn't require the runtime to be installed. With that in mind, you're right they should be included, which would increase the build size by 8.3 MB. > How about linux/Mac targets? I can't build a Mac target because I don't have a Mac. I just built for a linux-x64 target in WSL, and the resulting binary is 35.0 MB. The Linux build looks like it's packaged the CLR into the main binary instead of keeping them separate, which would account for the greater size. I did do a benchmark with hyperfine, which gave a 25.5 second build time. However, this is on WSL1 building off and on to an NTFS drive, which has known performance issues. > I think 20-30MB is quite good - puts it in the ballbark of golang. I've never used Go, but my understanding is that the Go compiler is very fast but doesn't do as much in the way of optimizations. If that's the case, having a larger and slower binary compared to Rust would be expected before you get to the packaged runtime. The issue I'm taking here is that doing a trimmed dotnet build is (in this case) giving the same build time as Rust, but is only doing some AoT compilation and dead-code elimination. Rust is already doing that in addition to a whole host of other optimizations. From a user perspective, this feels like dotnet is giving me a worse end product for the same time taken. Especially given the Rust version wasn't harder to write than the C# version (in fact, due to bad documentation the C# version was harder). > 2MB+ for rust actually sounds a bit big -that's stripped? No, that is not stripped, and with the standard release profile.
josteink 5y ago
> but as a Linux programmer, I found it difficult to install the dotnet sdk without the root permission It’s a tarball. Unpack it wherever you like. What exact problems did you have? Edit: I’ve even “installed” the .NET SDK on ARM/Aarch64 devices this way. Zero issues.
- attractivechaos 5y ago
  The lack of the ICU library. As you mention it, I searched around and found setting "export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true" could solve the problem. I stand corrected. Nonetheless, adding an env variable is still an extra step especially when the dotnet cli doesn't tell you what to do. An enduser has to google around to find the answer.
  - BuckRogers 5y ago
    >An enduser has to google around to find the answer. Welcome to Linux?? Not to be sarcastic but if you want your hand held install Windows for your .Net development. It's pretty nice over there.
    - jsight 5y ago
      > Welcome to Linux?? Maybe more like, "Welcome to MS tools on Linux?" There are no similar issues with installing a JDK, for example.
      - josteink 5y ago
        The OP is complaining about needing root to satisfy som third-party library dependency (libicu) when installing the .NET SDK outside the system package-manager, with the tarball only. I think that’s a pretty far fetched complaint. There are tons of software out there on Linux which will break if you don’t satisfy their dependencies. I’m sure the OpenJDK-tarball has some system-wide dependencies too (libssl?), but you can’t tell that because you probably installed it as root, using a package-manager instead. If you do the same with the .NET SDK (use root, install via package-manager) you will find everything working equally smooth.
boudin 5y ago
You can use dotnet-install for that https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-in...
e12e 5y ago
Of all the possible ways to handle toolchains on Linux, I'm quite happy with asdf[1]. I've successfully built stand-alone fsharp/csharp "Hello worlds" off of dotnet via asdf - but I've not used dot.net in anger. I chiefly like asdf because I typically need at least two toolchains (with various versions for various projects) - eg ruby and nodejs, or python and nodejs. https://asdf-vm.com/ https://asdf-vm.com/ https://github.com/emersonsoares/asdf-dotnet-core https://github.com/emersonsoares/asdf-dotnet-core

cebert 5y ago

You don’t need to install the SDK to run a dotnet core app. They can ship what’s required to run and there’s even single executable options now as well.

spaetzleesser 5y ago
One caveat: If you ship a self contained app you often end up with 200MB of assemblies to ship. and the single file executables tend to load very slowly. It's basically an archive that first gets extracted and then executed. I had to give that up with a recent app because it was just too slow.
- kqr 5y ago
  Yes, this deployment option makes tradeoffs that are clearly more in line with the use case of pushing out long-running server applications to machines with minimal configuration, rather than for desktop user applications.
  - spaetzleesser 5y ago
    That’s my impression too. Seems these days in general desktop applications are more of an afterthought in the .NET world and most new features are built mainly for server stuff.
- GordonS 5y ago
  This hasn't actually been the case since dotnet Core 2. Since dotnet Core 3, you can use assembly trimming to remove unused assemblies. That results in a package of around 10MB for a Hello World app, or more like 40-70MB for large, real-world apps. From dotnet 5 there is also member trimming, which will trim unused parts of assemblies, which will further reduce the size. I haven't used this yet, but Microsoft claim it can result in packages 5x smaller than with assembly trimming, e.g. only 2MB for a Hello World app. There is also AOT compilation, but I wouldn't hold my breath on seeing that become production-ready any time soon (Microsoft have been hyping it and saying it's "coming soon" for 10 years or so).
  - Measter 5y ago
    I just tried it on a small project of mine. It's 955 lines of C#[0], 6 dependencies, already configured for publishing a single file, self contained, for win-x64, ready to run. I built in release mode with publish trimmed, and trim mode set to link. The final size of the binary is 24.6 MB (not counting CLR DLLs), with a build time of 23.2[1] seconds. I also have a Rust version of the project. 710 lines of Rust[0], 128 total dependencies in the tree, building in release mode with the MSVC Windows compiler. Final size of the binary is 2.29 MB, build time of 22.2[1] seconds. Things are not great when your build times rival Rust's, and the output is slower and an order of magnitude bigger. [0] Note that the C# version does have more robust handling when writing its output file than the Rust version, which adds couple dozen lines. Also the style conventions for brackets puts opening brackets on a new line for C#, the same line for Rust. [1] Measured with hyperfine configured to run "dotnet clean -c Release" and "cargo clean" before each run.
    - e12e 5y ago
      > not counting CLR DLLs Why would you exclude those in this comparison - they're already (guaranteed to be) installed on your windows targets? How about linux/Mac targets? I think 20-30MB is quite good - puts it in the ballbark of golang. 2MB+ for rust actually sounds a bit big -that's stripped?
      - Measter 5y ago
        > > not counting CLR DLLs > Why would you exclude those in this comparison - they're already (guaranteed to be) installed on your windows targets? Note that this is a stand-alone build; it doesn't require the runtime to be installed. With that in mind, you're right they should be included, which would increase the build size by 8.3 MB. > How about linux/Mac targets? I can't build a Mac target because I don't have a Mac. I just built for a linux-x64 target in WSL, and the resulting binary is 35.0 MB. The Linux build looks like it's packaged the CLR into the main binary instead of keeping them separate, which would account for the greater size. I did do a benchmark with hyperfine, which gave a 25.5 second build time. However, this is on WSL1 building off and on to an NTFS drive, which has known performance issues. > I think 20-30MB is quite good - puts it in the ballbark of golang. I've never used Go, but my understanding is that the Go compiler is very fast but doesn't do as much in the way of optimizations. If that's the case, having a larger and slower binary compared to Rust would be expected before you get to the packaged runtime. The issue I'm taking here is that doing a trimmed dotnet build is (in this case) giving the same build time as Rust, but is only doing some AoT compilation and dead-code elimination. Rust is already doing that in addition to a whole host of other optimizations. From a user perspective, this feels like dotnet is giving me a worse end product for the same time taken. Especially given the Rust version wasn't harder to write than the C# version (in fact, due to bad documentation the C# version was harder). > 2MB+ for rust actually sounds a bit big -that's stripped? No, that is not stripped, and with the standard release profile.

josteink 5y ago

> but as a Linux programmer, I found it difficult to install the dotnet sdk without the root permission It’s a tarball. Unpack it wherever you like. What exact problems did you have? Edit: I’ve even “installed” the .NET SDK on ARM/Aarch64 devices this way. Zero issues.

attractivechaos 5y ago
The lack of the ICU library. As you mention it, I searched around and found setting "export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true" could solve the problem. I stand corrected. Nonetheless, adding an env variable is still an extra step especially when the dotnet cli doesn't tell you what to do. An enduser has to google around to find the answer.
- BuckRogers 5y ago
  >An enduser has to google around to find the answer. Welcome to Linux?? Not to be sarcastic but if you want your hand held install Windows for your .Net development. It's pretty nice over there.
  - jsight 5y ago
    > Welcome to Linux?? Maybe more like, "Welcome to MS tools on Linux?" There are no similar issues with installing a JDK, for example.
    - josteink 5y ago
      The OP is complaining about needing root to satisfy som third-party library dependency (libicu) when installing the .NET SDK outside the system package-manager, with the tarball only. I think that’s a pretty far fetched complaint. There are tons of software out there on Linux which will break if you don’t satisfy their dependencies. I’m sure the OpenJDK-tarball has some system-wide dependencies too (libssl?), but you can’t tell that because you probably installed it as root, using a package-manager instead. If you do the same with the .NET SDK (use root, install via package-manager) you will find everything working equally smooth.

boudin 5y ago

You can use dotnet-install for that https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-in...

e12e 5y ago

Of all the possible ways to handle toolchains on Linux, I'm quite happy with asdf[1]. I've successfully built stand-alone fsharp/csharp "Hello worlds" off of dotnet via asdf - but I've not used dot.net in anger. I chiefly like asdf because I typically need at least two toolchains (with various versions for various projects) - eg ruby and nodejs, or python and nodejs. https://asdf-vm.com/ https://asdf-vm.com/ https://github.com/emersonsoares/asdf-dotnet-core https://github.com/emersonsoares/asdf-dotnet-core