Saved modules grow in size

I compile an assembly using Visual Studio 2010, C#. Target Framework is version 4 Client Profile. Output type is class library. Platform target is Any CPU. Optimize code is on. Allow Unsafe code is off. There are no managed resources and no native resources. The assembly is signed (strong name).

The PE Header says: Section Alignment = 8192 File Alignment = 512

.text section is 254 KB .rsrc section is 1 KB .reloc section is 512 bytes

CLR Header says MetaData is 147,59 KB

Total file size is 256 KB.

I then open the module using

ModuleDefinition md = ModuleDefinition.ReadModule(modulepath);

and save it using

WriterParameters wp = new WriterParameters
{
    WriteSymbols = md.HasSymbols
};

md.Write(modulepath, wp);

The new file is now 258.5 KB.

The .text section has grown to 255.5 KB A .sdata section has been added, 512 bytes

CLR Header says MetaData is now down to 147.5 KB.

The .text section should not grow. A .sdata section should not be added. The total file size should not increase (It would be ok if it went down without loosing information).

I have not tested this on other modules.

[KrisVandermotten]

I don’t think it’s fear, rather prudence, being careful. I’ve tracked down many bugs in my time based on a smell.

Also, unit tests are very valuable, but they’re just that: unit tests. In addition to unit tests, I always run a battery of static analysis tools on my code. Often I also perform stress tests and other kinds of tests.

In this specific case, I run evertything that comes out of Cecil (after being modified by my code) through its battery of tests and validations, but also through peverify and other low level pe file analysers. I will also look at JIT compiler output, to verify that my modifications do not disable JIT optimizations.

Like you say, there can be an obscure bug everywhere, but the more eyes (tests and validaion tools) look at the code (in different ways), the smaller the chances are.

[SimonCropp]

@jbevain think this one can be closed