3 ms·

Since you've looked into .NET 5.0 - is it possible now to create a single .exe, and not having to carry extra .dlls (I'm still stuck to .NET Framework 4.7.2 for

by malkia 6y ago

Since you've looked into .NET 5.0 - is it possible now to create a single .exe, and not having to carry extra .dlls (I'm still stuck to .NET Framework 4.7.2 for one reason or another).

oblio 6y ago
It's just a fancy self-extracting archive... it's not a statically linked binary with tree shaking of everything which is not actually used.
- malkia 6y ago
  ugh - I was expecting something better, then again while probably .NET bytecode maybe more mergeable (Without knowing much about it, assuming "java" like essence), there is still the issue of "pdb" merging (but that should be doable...). Obviously native is problematic. Back at Google, I really like how this was solved. Bazel (blaze) internally when doing java or python tool - would actually compile the java runner to become the main app, then the .jar (combined) could be part of it (not sure right now, but it could be), and any native C/C++ JVM code would be part of the java runner (all statically linked) - so you end up with single executable. Same for python - any C/C++ linked externally becomes part of the "python.exe" (sorry, I'm mostly on windows terms now) + the rest of the compiled .python code - may go as .zip with the .exe - or even directly embedded as some data. I really hope Microsoft goes this way. Distributing single (ok, two with .pdb) executables goes a long way of easing the process - CI, tools, or just here is a tool (to a coworker) that would work for you, and right now is... oh, and you need these extra .dlls (and app.config, and now .dll.recipe files, and who knows what else). I do really wish .NET comes to realize that single true binary is a must (without temp files extracting, this is so prone to errors, security issues, leaks, etc.)
  - manigandham 6y ago
    You should read the docs because it's already available: https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
    - malkia 6y ago
      Thanks!! - Awesome to hear about this - ".NET 5.0 improves this experience by directly running the code without the need to extract the files from the app." - phew - feel relieved, I can convince now folks to upgrade to 5.0
- ynik 6y ago
  In .NET Core 3.1 it was a self-extracting archive; I think in .NET 5.0 the assemblies are directly mmapped from the .exe without an extraction step. Also, you can enable some tree shaking: https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming-options https://docs.microsoft.com/en-us/dotnet/core/deploying/trimm... But tree shaking can be problematic if the application uses Reflection.
  - oblio 6y ago
    > But tree shaking can be problematic if the application uses Reflection. Reflection is common.
moron4hire 6y ago
that's coming in .NET 6.0
vborovikov 6y ago
There will be some required .dlls with your .exe. The size of .exe for a simple console app is around 60 Mb.

by malkia 6y ago

Since you've looked into .NET 5.0 - is it possible now to create a single .exe, and not having to carry extra .dlls (I'm still stuck to .NET Framework 4.7.2 for one reason or another).

oblio 6y ago

It's just a fancy self-extracting archive... it's not a statically linked binary with tree shaking of everything which is not actually used.

malkia 6y ago
ugh - I was expecting something better, then again while probably .NET bytecode maybe more mergeable (Without knowing much about it, assuming "java" like essence), there is still the issue of "pdb" merging (but that should be doable...). Obviously native is problematic. Back at Google, I really like how this was solved. Bazel (blaze) internally when doing java or python tool - would actually compile the java runner to become the main app, then the .jar (combined) could be part of it (not sure right now, but it could be), and any native C/C++ JVM code would be part of the java runner (all statically linked) - so you end up with single executable. Same for python - any C/C++ linked externally becomes part of the "python.exe" (sorry, I'm mostly on windows terms now) + the rest of the compiled .python code - may go as .zip with the .exe - or even directly embedded as some data. I really hope Microsoft goes this way. Distributing single (ok, two with .pdb) executables goes a long way of easing the process - CI, tools, or just here is a tool (to a coworker) that would work for you, and right now is... oh, and you need these extra .dlls (and app.config, and now .dll.recipe files, and who knows what else). I do really wish .NET comes to realize that single true binary is a must (without temp files extracting, this is so prone to errors, security issues, leaks, etc.)
- manigandham 6y ago
  You should read the docs because it's already available: https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
  - malkia 6y ago
    Thanks!! - Awesome to hear about this - ".NET 5.0 improves this experience by directly running the code without the need to extract the files from the app." - phew - feel relieved, I can convince now folks to upgrade to 5.0
ynik 6y ago
In .NET Core 3.1 it was a self-extracting archive; I think in .NET 5.0 the assemblies are directly mmapped from the .exe without an extraction step. Also, you can enable some tree shaking: https://docs.microsoft.com/en-us/dotnet/core/deploying/trimming-options https://docs.microsoft.com/en-us/dotnet/core/deploying/trimm... But tree shaking can be problematic if the application uses Reflection.
- oblio 6y ago
  > But tree shaking can be problematic if the application uses Reflection. Reflection is common.

moron4hire 6y ago

that's coming in .NET 6.0

vborovikov 6y ago

There will be some required .dlls with your .exe. The size of .exe for a simple console app is around 60 Mb.