How can I know if an "assembly" really did change?

Question

I created a simple "Hello World" application in VS2005. It's a straight-forward console application; it only contains the following lines:

Console.WriteLine("Hello World");
Console.ReadLine();

When I tried to rebuild the same console application WITHOUT performing any changes (just press the rebuild button), I get a subtly different executable. (I generated a SHA-1 hash from both the 1st and 2nd generated executable, and it's different!)

Why is it different when there are no code changes? What actually changed? I used a hex editor to compare and only saw a couple different bytes.

I guess my ultimate question is, how can I know if an "assembly" really did change? (Of course without looking at File versions, file size, etc)

EDIT

So far, we've established that the difference lies in the PE header (timestamp and some debug data). Before I re-invent the wheel, is there an "assembly comparison" tool that ignores the PE header?

Thanks, Ian

Answer 1

The differences will be

• the timestamp in the PE header
• the GUID of the debug data, if present

(and maybe something more, as per the other output you've posted?) To see these, run dumpbin /all /rawdata:none on both assemblies in a VS command prompt.

To do this properly you'd have to write a comparison tool that understood this and ignored those bytes - or took copies of the executables, cleared the timestamp and GUID and then compared those versions. Or, at a pinch, you could use something like fc /b as controlfreak suggests and assume that if there are < 20 bytes different (4 for the timestamp, 16 for the GUID) then it's probably the same.

You may well get away with using an assembly with the timestamp cleared - AFAIK it's only used to cache exported symbol offsets in other DLLs if you hook that up - but it's probably safer to leave as is. If you actually need binary-identical assemblies I suggest you change your processes so you never clean-build unless you really need it.