5 ms·

It's been a few years, but I worked on a dotnet core C# project once. Prod was Linux and dev usually OSX. I remember running a dotnet build to generate some kin

It's been a few years, but I worked on a dotnet core C# project once. Prod was Linux and dev usually OSX. I remember running a dotnet build to generate some kind of artifact (dll maybe) that still needed the SDK to run. Is there some other way to do it that made a self contained executable?

atraac 5y ago
Yes, since I believe 2.1 you can make a self contained executable with sdk included using dotnet publish. You can read more about it here: https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ...
- quaffapint 5y ago
  The nice thing they also added was the ability to trim the self-contained app, so it doesn't include a lot of unnecessary assemblies. https://docs.microsoft.com/en-us/dotnet/core/deploying/trim-self-contained https://docs.microsoft.com/en-us/dotnet/core/deploying/trim-...
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 ago
  The binary is that big on Linux because the debug symbols are embedded in the executable. You need to strip them.
  - GordonS 5y ago
    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.
    - rcarmo 5y ago
      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.
  - gregmac 5y ago
    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)
mdasen 5y ago
Yes, .NET Core can now create self-contained executables. Microsoft and others have been enhancing this since it was introduced in .NET Core 2.1. I've been enjoying the way that .NET has been evolving in pragmatic ways. The initial implementation basically created a self-extracting zip that would include the runtime. That had its drawbacks, but it was a way for them to get self-contained deployable out the door with minimal hassle. Sure, it meant taking up a bit more space, but it worked and solved what most people cared about: having a single file that they could run without needing to install things in the OS. Likewise, they came up with ReadyToRun. Basically, they'd AOT-compile stuff for fast startup times, but include the byte code so that things could be JIT-compiled during runtime. This meant that the AOT-compiler didn't need to be perfect and that they didn't need to worry too much about things like the performance of reflection code. That code would end up JIT-compiled in long-running programs. Again, a pragmatic approach that does have some drawbacks (like large deployable artifacts), but they got it out the door and have been improving it as time goes forward. A more pure approach might be to wait until one can produce a really top-notch AOT compiler, wait until one can replace certain reflection-heavy code, wait until one can optimize libraries, wait until one can do lots of testing to make sure you don't have regressions, etc. But that requires a lot of time while what a lot of people might want isn't a pure solution, but just something that allows them to speed up start times. Likewise, zipping up the runtime with your code into a self-extracting and self-running file isn't the most pure approach, but it meant that you could get a single file to scp and just do `./myprogram` on.
- MarkSweep 5y ago
  The self extracting is gone for Linux in .NET 5 and gone for Windows in the upcoming .NET 6. If any copying still happens, it just within the memory space of the process. If you include extra DLL or .so files, those still have to be extracted so that the operating system dynamic linker can load them.
  - mdasen 5y ago
    Yep! It's one of the things that's nice about the .NET ecosystem. We didn't have to wait for self-contained executables and got them back in 2018 (even if it wasn't perfect, it worked well enough) and they refined it as time went along in a way that didn't require me to do things. Microsoft could have waited until .NET 5/6 to offer self-contained executables "the right way", but they were able to create something that offered 90% of people what they wanted a few years earlier.

atraac 5y ago

Yes, since I believe 2.1 you can make a self contained executable with sdk included using dotnet publish. You can read more about it here: https://docs.microsoft.com/en-us/dotnet/core/deploying/#publish-self-contained https://docs.microsoft.com/en-us/dotnet/core/deploying/#publ...

quaffapint 5y ago
The nice thing they also added was the ability to trim the self-contained app, so it doesn't include a lot of unnecessary assemblies. https://docs.microsoft.com/en-us/dotnet/core/deploying/trim-self-contained https://docs.microsoft.com/en-us/dotnet/core/deploying/trim-...

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 ago
The binary is that big on Linux because the debug symbols are embedded in the executable. You need to strip them.
- GordonS 5y ago
  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.
  - rcarmo 5y ago
    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.
- gregmac 5y ago
  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)

mdasen 5y ago

Yes, .NET Core can now create self-contained executables. Microsoft and others have been enhancing this since it was introduced in .NET Core 2.1. I've been enjoying the way that .NET has been evolving in pragmatic ways. The initial implementation basically created a self-extracting zip that would include the runtime. That had its drawbacks, but it was a way for them to get self-contained deployable out the door with minimal hassle. Sure, it meant taking up a bit more space, but it worked and solved what most people cared about: having a single file that they could run without needing to install things in the OS. Likewise, they came up with ReadyToRun. Basically, they'd AOT-compile stuff for fast startup times, but include the byte code so that things could be JIT-compiled during runtime. This meant that the AOT-compiler didn't need to be perfect and that they didn't need to worry too much about things like the performance of reflection code. That code would end up JIT-compiled in long-running programs. Again, a pragmatic approach that does have some drawbacks (like large deployable artifacts), but they got it out the door and have been improving it as time goes forward. A more pure approach might be to wait until one can produce a really top-notch AOT compiler, wait until one can replace certain reflection-heavy code, wait until one can optimize libraries, wait until one can do lots of testing to make sure you don't have regressions, etc. But that requires a lot of time while what a lot of people might want isn't a pure solution, but just something that allows them to speed up start times. Likewise, zipping up the runtime with your code into a self-extracting and self-running file isn't the most pure approach, but it meant that you could get a single file to scp and just do `./myprogram` on.

MarkSweep 5y ago
The self extracting is gone for Linux in .NET 5 and gone for Windows in the upcoming .NET 6. If any copying still happens, it just within the memory space of the process. If you include extra DLL or .so files, those still have to be extracted so that the operating system dynamic linker can load them.
- mdasen 5y ago
  Yep! It's one of the things that's nice about the .NET ecosystem. We didn't have to wait for self-contained executables and got them back in 2018 (even if it wasn't perfect, it worked well enough) and they refined it as time went along in a way that didn't require me to do things. Microsoft could have waited until .NET 5/6 to offer self-contained executables "the right way", but they were able to create something that offered 90% of people what they wanted a few years earlier.