recommended way to analyze size of output binary

[redthing1]

I followed the instructions for the MonoGame sample to publish to a native binary compiled with CoreRT.

However, the output size is quite a bit larger with my application than with this template application, and I would like to figure out what is contributing to the size. My application references multiple packages and other assemblies, but I am not sure how much each of those contribute to the size. Ostensibly, not that much; I looked at the file sizes from a dotnet publish using CoreCLR and they are in the few KB, while my CoreRT binary is upwards of 50MB. With the minimal MonoGame application, it is about 9MB, which is closer to what I am targeting.

How could I diagnose exactly what is causing my CoreRT binaries to be so large?

[jkotas]

Some of the package referenced by your application are likely bringing in large chunk of the framework and it makes the final binary large.

The easiest way to find out is probably to comment out the dependencies on the individual packages and see how it affects your application size.

Are the packages referenced by your application published on nuget.org? Maybe you can share their names. Some packages (e.g. System.Reactive) are well known for having very complex generics that expand into a lot of code.

[redthing1]

nope, all the packages i am using are my own internal libraries. as such it's difficult to simply comment out a reference to them.

also, if i am understanding correctly, wouldn't the linker be eliminating dead code? so that even if i were able to track down the size to a single library, nothing really short of removing it could help me further minimize the size, right?

[redthing1]

i was wondering if there was a way to inspect the assemblies bundled in the native output binary, and thus see each of their sizes.

i am on Ubuntu Linux, if it is relevant.

are there any tools that I could use to do this? and how would I go about analyzing them.

[MichalStrehovsky]

Adding <IlcGenerateMapFile>true</IlcGenerateMapFile> will create a *.map file in the intermediate build output directory (the obj directory, by default. This file describes all that was generated, including sizes.

There are some bits of info here: #7962

Otherwise here's a doc with a bunch of switches that might be of interest for you: https://github.com/dotnet/corert/blob/master/Documentation/using-corert/optimizing-corert.md

[redthing1]

oh, that looks like exactly what I was looking for! thank you very much, i will take a look