Comment by gregmac | Hacker News Reader

Comment by gregmac | Hacker News Reader

Parent Full thread

Yep. One of the things I've been doing lately with some internal utility apps is building a small Windows exe (for Workstations where almost always the dotnet runtime is already installed), and a larger but self-contained binary for linux.

    dotnet publish -r win-x64 -p:PublishSingleFile=true ---self-contained=false

    dotnet publish -r linux-x64 -p:PublishSingleFile=true -p:PublishTrimmed=true --self-contained=true

To give an example of this for a reasonably complex test tool I have on .NET core 3.1, the Windows exe is 3.7MB and the linux binary is 38MB. I'm guessing there's some room for optimization in the process though, as the linux binary is compressed (tgz) to 13.37MB.

The binary is that big on Linux because the debug symbols are embedded in the executable. You need to strip them.

Huh, the debug symbols are in separate .pdb files, aren't they?

38MB is a pretty typical size for a real-world, self-contained, assembly-trimmed package, and the size comes from the runtime itself, plus the core assemblies that weren't trimmed out.

Actually, in my tests with the AoT compiler I had to strip the binary to get a significantly smaller one despite there being a .pdb file. Your mileage may vary as the build flags can be a bit fiddly.

In the interest of keeping the comment small, I omitted a couple things:

    -p:Configuration=Release -p:DebuggerSupport=false

FWIW, I did also try the following, but found they had basically no impact on output size:

    -p:TrimMode=link
    -p:EnableUnsafeBinaryFormatterSerialization=false 
    -p:EnableUnsafeUTF7Encoding=false 
    -p:EventSourceSupport=false 
    -p:HttpActivityPropagationSupport=false

(Tested on .NET Core 3.1.5)

Reply on news.ycombinator.com