WPF .exe - large filesize

Question

I am working on a WPF application and the .exe is found to be over 1.2MB in size. I would like to reduce the size of the final executable. The code is no more than a few 200 Kb, I use a few .png images in the project, which alltogether takes up about 20kb. Why is the final executable so big? I used ILDASM statistics to take a look at the .exe statistics. Posting the output below:

File size            : 1267712
 PE header size       : 512 (496 used)    ( 0.04%)
 PE additional info   : 1547              ( 0.12%)
 Num.of PE sections   : 3
 CLR header size     : 72                 ( 0.01%)
 CLR meta-data size  : 72524              ( 5.72%)
 CLR additional info : 1160002            (91.50%)
 CLR method headers  : 3189               ( 0.25%)
 Managed code         : 28702             ( 2.26%)
 Data                 : 2048              ( 0.16%)
 Unaccounted          : -884              (-0.07%)

 Num.of PE sections   : 3
   .text    - 1265152
   .rsrc    - 1536
   .reloc   - 512

 CLR meta-data size  : 72524
   Module        -    1 (10 bytes)
   TypeDef       -   58 (812 bytes)     0 interfaces, 0 explicit layout
   TypeRef       -  250 (1500 bytes)
   MethodDef     -  647 (9058 bytes)    0 abstract, 0 native, 639 bodies
   FieldDef      -  216 (1296 bytes)    10 constant
   MemberRef     -  481 (2886 bytes)
   ParamDef      -  460 (2760 bytes)
   MethodImpl    -   11 (66 bytes)
   Constant      -   11 (66 bytes)
   CustomAttribute-  506 (3036 bytes)
   StandAloneSig -   73 (146 bytes)
   InterfaceImpl -   27 (108 bytes)
   PropertyMap   -   29 (116 bytes)
   Property      -  233 (1398 bytes)
   MethodSemantic-  304 (1824 bytes)
   TypeSpec      -   30 (60 bytes)
   Assembly      -    1 (22 bytes)
   AssemblyRef   -   13 (260 bytes)
   ManifestResource-    2 (24 bytes)
   NestedClass   -   17 (68 bytes)
   EventMap      -    5 (20 bytes)
   Event         -    7 (42 bytes)
   MethodSpec    -   12 (48 bytes)
   Strings       - 21669 bytes
   Blobs         - 18740 bytes
   UserStrings   -  6244 bytes
   Guids         -    16 bytes
   Uncategorized -   229 bytes

 CLR additional info : 1160002
   Resources         - 1160002

 CLR method headers : 3189
   Num.of method bodies  - 639
   Num.of fat headers    - 169
   Num.of tiny headers   - 470
   Num.of fat sections   - 3
   Num.of small sections - 25

 Managed code : 28702
   Ave method size - 44

As you can see, the CLR additional info takes up most of the space. I am using all visual styles in my project as StaticResource, which I think makes no big difference? How can the large .exe size be explained? (Building the project in release mode x64 )

UPDATE:

My build options are :

Configuration - Release
Platform - x64
Optimize code - enabled
Allow unsafe code - disabled
Conditional comppilation symbols - none

Answer 1

This is probably an issue with embedded resources.

If you added images or other resources to the project, even if you delete the file from the project, the resource will remain embedded.

Check the Resources section of project properties.

For example, did you add your images as bitmaps first and later deleted the files and added as png?

Answer 2

Indirectly referenced default styles with all dependencies they have are usually not visible in code or XAML. I am not sure but if WPF is embedding them into the exe, this could account for some of the overhead. You could test this by removing most of the WPF-dependent code to see whether this significantly influences file size.

There could also be an overhead due to being WPF and being executable. You could test this by putting your code into a WPF Custom or User Control Library Project. This can be created by visual studio. If for the same content the resulting DLLs are much smaller than the EXE-files, it might be a combination of WPF and being an executable.

In general, I find a file size overhead not surprising. As a big framework WPF is not known for its tininess and efficiency.

The two comments to the answer here: "Why is my .net exe so huge" analyzer tool? might also be helpful.