8 ms·
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 r
by gregmac 5y ago
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.
- andrewmd5 5y agoThe binary is that big on Linux because the debug symbols are embedded in the executable. You need to strip them.
- GordonS 5y agoHuh, 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.
- rcarmo 5y agoActually, 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.
- gregmac 5y agoIn 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)