Why is a different dll produced after a clean build, with no code changes?

Question

When I do a clean build my C# project, the produced dll is different then the previously built one (which I saved separately). No code changes were made, just clean and rebuild.

Diff shows some bytes in the DLL have changes -- few near the beginning and few near the end, but I can't figure out what these represent. Does anybody have insights on why this is happening and how to prevent it?

This is using Visual Studio 2005 / WinForms.

Update: Not using automatic version incrementing, or signing the assembly. If it's a timestamp of some sort, how to I prevent VS from writing it?

Update: After looking in Ildasm/diff, it seems like the following items are different:

• Two bytes in PE header at the start of the file.
• <PrivateImplementationDetails>{guid} section
• Cryptic part of the string table near the end (wonder why, I did not change the strings)
• Parts of assembly info at the end of file.

No idea how to eliminate any of these, if at all possible...

Avid

Answer 1

My best guess would be the changed bytes you're seeing are the internally-used metadata columns that are automatically generated at build-time.

Some of the Ecma-335 Partition II (CLI Specification Metadata Definition) columns that can change per-build, even if the source code doesn't change at all:

• Module.Mvid: A build-time-generated GUID. Always changes, every build.
• AssemblyRef.HashValue: Could change if you're referencing another assembly that has also been rebuilt since the old build.

If this really, really bothers you, my best tip on finding out exactly what is changing would be to diff the actual metadata tables. The way to get these is to use the ildasm MetaInfo window:

View > MetaInfo > Raw:Header,Schema,Rows // important, otherwise you get very basic info from the next step

View > MetaInfo > Show!

Eileen

Answer 2

I think that would be the TimeDateStamp field in the IMAGE_FILE_HEADER header of the PE32 specifications.

Gershwin

".. how to I prevent VS from writing it?" I'm not sure if you can tell the linker not to write the TimeDateStamp field in the PE 32 header. The workaround would be to write an utility that clears the TimeDateStamp field in you post-build event in VS. – Gershwin

I would also like to know how to prevent this from being included. Then we can only ship the assemblies that have changed since the last version. – Poisoning

Answer 3

Could be that the build or revision numbers have changed.

Unger