[question] Why not uncompressed executables?

[sebastienros]

Just because space matters? Or is that a convention that all executables should be compressed. Assuming I run Windows (I do), what is the workflow? I would assume use curl to download the file from GitHub, then uncompress it myself? Or is there some magic command line arguments taht can do it all for me?

Maybe that could be something to add in the docs as a guidance for the users to add to their docs? (like me).

[xoofx]

Just because space matters? Or is that a convention that all executables should be compressed. Assuming I run Windows (I do), what is the workflow? I would assume use curl to download the file from GitHub, then uncompress it myself? Or is there some magic command line arguments taht can do it all for me?

So the rationale is:

• It's the convention of how other ecosystems are working for such things (see Go repos shipping executables. Example with e.g hugo)
• Having archives allows to have the same exe name (e.g helloworld.exe) no matter the CPU target. It's only the zip filename that contains the CPU (e.g helloworld-win-x64.zip) but inside the app name and layout is the same.
• Some executables can have satellites files (config/external files...etc.), so having the same way of distributing an app is easier
• Some browsers/OSS are stupid and blocking you to download exe file directly
• Windows sucks at distributing easily installable apps. dotnet-releaser doesn't solve this 😬 . I'm waiting for winget to come with proper support for zip so that it can make this better.
• Because Microsoft.Extensions.Logging requires it 🤡

If you are just generating just one exe for Windows and you just care about the exe, running msbuild publish is probably the easiest route for your case, dotnet-releaser is not really helping there... Otherwise unzipping it from a powershell is still possible.

[sebastienros]

No I want it to ship all the targets. Just wondering what the best workflow is for windows and zip files. Thanks for the other explanations.

[xoofx]

Also, yes, somehow from your original question about space, compressing these executables is usually worth it. Having an executable that is 70MB while it could be 20MB is easier to sell. Some, like me, had still ADSL2 connection no longer than 2 months ago, so with 17Mbps download, that matters. Worse for the upload at 1.7Mbps, I remember having big trouble to upload packages from my home to GitHub when not running from GitHub Action. I just upgraded to a Starlink connection with 300Mbps, but I still remember the old me, and I know that many folks around the world don't even have an ADSL2 connection.

[xoofx]

Another example with satellite files: for grpc-curl I'm adding license and readme.md files to my publish archive. It is quite a common pattern to put these along your exe. See Hugo where they ship their license+readme as well.

If you feel that it is something super important to have single exe file distribution, feel free to submit a PR, with an option to enable it (e.g PackageKind.Exe) and a safe-guard that will unzip the zip/tar.gz created and before repackaging it to a single exe while checking that the archive contained only a single file (it could be done at msbuild level, but depending on your knowledge there, that could be less easy). It is likely also that you will have to rename the exe with the platform postfix, as GitHub releases don't expect to have identical file names. So all in one, it's quite some work to get this done, and I have no incentive for my personal usage, but a PR is welcome. 🙂

[sebastienros]

Awesome, thank you