"Why is my .net exe so huge" analyzer tool?

Question

Is there a tool that can explain the size of a .NET assembly (executable or DLL file)?

In the olden days, there was an IDE extension that would detail the space used by a project.

It should show the large code files:

And data resources:

Is there such a thing for the .NET world?

I really thought that moving to .NET, and no longer having to build the entire VCL into the executable, that executable sizes would shrink.

Bonus Reading

Analyze space used by .NET assembly

This question is confusing. Are you working in .NET? The dialogs you included are for Delphi Win32 apps. Are you using Delphi for .NET? If so, you should include that in your tags (and provide info about what compiler options you're using). — Ken White, Feb 16 '12 at 15:20
@KenWhite i ***am*** indeed working in .NET. The dialogs i included are for Delphi Win32 apps (i.e. *the olden days*). This question is for .NET and .NET assemblies. i *happen* to be working in Visual Studio 2010. Although i suppose any valuable tool could analyze any .NET assembly, no matter the compiler used to create it (including DFDN) — Ian Boyd, Feb 16 '12 at 15:29
As I said, your question was confusing. (It still is, in fact.) You mention an "IDE extension", but that wasn't a VS IDE extension, you mention "build the entire VCL", and show Delphi project dialogs, and don't mention any IDE/language in your tags. — Ken White, Feb 16 '12 at 15:37
@KenWhite It was an inside nod to those who still know about a language that has 4% market share. — Ian Boyd, Feb 16 '12 at 15:44
@KenWhite Which part don't you understand, perhaps i can clarify. — Ian Boyd, Feb 16 '12 at 16:56
@Ian, if your "market share" remark referred to Delphi, you need to update your facts (and apparently your product knowledge). :) Delphi's user base has been growing over the past couple of years, and the newly released XE2 supports 64-bit and XPlatform (OS X and iOS). Since you got an answer to your question, it was apparently clear enough. My mistake. — Ken White, Feb 16 '12 at 17:03
@KenWhit http://langpop.com/ "Delphi" and "Pascal" combined don't quite reach 5%. It's a shame too. i use Delphi daily, and prefer it *greatly* to Visual Studio. — Ian Boyd, Feb 16 '12 at 18:06
@Ian, langpop is based on searches via various search sites. It's merit is highly debatable, and it's methodology is flawed. (It doesn't include, for instance, questions posted here directly, questions asked in other forums and groups, etc., and doesn't factor in the users that are experienced or familiar enough with Delphi and the WinAPI who don't search often (if at all)). According to EMBT, there are more than a million *licensed* Delphi users, and the number has increased steadily since it left Borland (since CodeGear was launched). It also doesn't include Delphi Prism (Pascal/.NET). — Ken White, Feb 16 '12 at 18:24

score 13 · Accepted Answer · edited Oct 08 '17 at 10:39

The standard SDK took ILDASM (IL Disassembler), had the "Statistics" option in the View menu, which broke it down like this:

 File size            : 3072
 PE header size       : 512 (456 used)    (16.67%)
 PE additional info   : 167               ( 5.44%)
 Num.of PE sections   : 2
 CLR header size     : 72                 ( 2.34%)
 CLR meta-data size  : 1572               (51.17%)
 CLR additional info : 0                  ( 0.00%)
 CLR method headers  : 15                 ( 0.49%)
 Managed code         : 77                ( 2.51%)
 Data                 : 512               (16.67%)
 Unaccounted          : 145               ( 4.72%)

 Num.of PE sections   : 2
   .text    - 2048
   .reloc   - 512

 CLR meta-data size  : 1572
   Module        -    1 (10 bytes)
   TypeDef       -    4 (56 bytes)      0 interfaces, 0 explicit layout
   TypeRef       -   15 (90 bytes)
   MethodDef     -    4 (56 bytes)      0 abstract, 0 native, 4 bodies
   FieldDef      -    2 (12 bytes)      0 constant
   MemberRef     -   15 (90 bytes)
   ParamDef      -    4 (24 bytes)
   CustomAttribute-   13 (78 bytes)
   StandAloneSig -    1 (2 bytes)
   Assembly      -    1 (22 bytes)
   AssemblyRef   -    1 (20 bytes)
   Strings       -   571 bytes
   Blobs         -   336 bytes
   UserStrings   -     8 bytes
   Guids         -    16 bytes
   Uncategorized -   181 bytes

 CLR method headers : 15
   Num.of method bodies  - 4
   Num.of fat headers    - 1
   Num.of tiny headers   - 3

 Managed code : 77
   Ave method size - 19

This should provide a good starting point.

Excellent starting point. Today i learned that Visual Studio stores my PNG compressed images as uncompressed BMPs. 1 MB of PNG images takes up 7.5 MB in the final 8MB assembly. *sigh* — Ian Boyd, Feb 16 '12 at 16:58
@IanBoyd You can have that image be appended as Content instead of as resource in the Properties Menu of the image. — balexandre, Feb 21 '12 at 12:07
@balexandre The "Content" build option means the file will be in the output directory - they won't be embedded within the output assembly. It sounds like the OP should use Manifest Resource Streams to store the PNG data instead. — Dai, Apr 19 '21 at 03:00

"Why is my .net exe so huge" analyzer tool?

Bonus Reading

1 Answers1

Linked