Could be let the compiled output be smaller?

[sgf]

First of all thank you for your hard work, in order to create such a great project. My question is: Could be let the compiled output be smaller?its too big now.

when im testing a hello world with webapi Program, the last output filesize need 21 mb+.

when im create a HelloWorld Console Program, the last output file size got about 3.86 mb.

oh my god,im just want it say hello,But its carry such a heavy burden. thats too big,any chance to let them smaller?

even golang or dlang is much more smaller. they also have GC,and The benefits of advanced languages.

[MichalStrehovsky]

What scenarios would having smaller deployment size enable for you?

[fanoI]

For example in the embedded world is typical to have little disk space (20 GB if you are lucky) so if we have a lot of Net Core app and anyone is more than 21 MB you will risk to fill all HDD!

[sgf]

lots of usage scenario need thats. when ppl update there services. for example 1 file is 10 mb.but if ppl has 10.thats will be 100mb. if one is only 500kb.then the total only need 5mb. the internet is Very unstable.Even the AWS S3 access in many parts of the world. Its speed even just a few KB.

more other Situations: 1.i think the Problem will take much more memory?am i right? because the PE File need load all in Memory to execute. 2.like fanol says,some time maybe we need run that in embedded OS,or docker. more size will take more disk and memory.maybe 1-2 file is ok.but which OS only running only 1-2 file at today. 3.Other things when I think of I would come here for supplement....

In fact, a lot of time people always prefer a more little size problems. Because they are easy to store, easy to carry, easy to transport. thank u.

[ShiningDev]

You're lucky, I usually get 7mb on my hello world program. I've tried using .net core 1.1, 2.0, and 2.1. No apparent size differences.

[MichalStrehovsky]

You're lucky, I usually get 7mb on my hello world program

Make sure to pass -c release to dotnet publish when you're publishing. The default is debug and those builds are bigger.

Thanks for the scenarios, @fanoI and @sgf. Having executable sizes that scale based on what you're using is definitely something I want to look at in the future (#5013).

[fanoI]

ILlinker is already used by CoreRt? Or all the .Net Framework is compiled?

Another possibility to mitigate the issue would be to:

1. Compile the Framework as a separate native DLL
2. Make all the applications use that DLL

So you transfer / install the framework native DLL only a time and the application will be more smaller having only their code inside.

[ShiningDev]

@MichalStrehovsky I use dotnet publish -r win-x86 -c Release

[MichalStrehovsky]

ILlinker is already used by CoreRt? Or all the .Net Framework is compiled?

We don't use ILLinker, but everything gets naturally treeshaken by the compiler itself (we start with compiling Main/NativeCallable exports and continue compiling other methods and generating necessary data structures as we go). If there's a type or method that is not used, the compiler doesn't even look at it.

Compile the Framework as a separate native DLL

We currently only have that compilation option in .NET Native for UWP apps. At some point we would like to bring this to the open source compiler too. A lot of the building blocks are already there.

[fiigii]

HelloWorld is 11M on OSX :)

[MichalStrehovsky]

@fiigii did you run strip on the executable? Outside Windows, things are big because symbols are big. Symbols are big because .NET namespaces are too long. Windows mitigates that by storing symbols separately.

[fiigii]

@MichalStrehovsky Thanks, after running strip HelloWorld, it becomes 6.1M.