How can I know if an “assembly” really did change?

问题

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

回答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.

回答2:

From a Visual Studio command prompt you can do a more elaborate comparison:

You could compare the PE header using the output of dumpbin:
```
dumpbin /HEADERS assembly.dll
```
Or you could compare PE headers and the IL code embedded in the assembly using ildasm:
```
ildasm /ALL /TEXT assembly1.dll > dump1.txt
ildasm /ALL /TEXT assembly2.dll > dump2.txt
fc dump1.txt dump2.txt        
```
The /ALL option will dump the DOS and PE headers, the CLR header, assembly metadata and disassembled IL. However, it will not contain embedded resources. If your assmembly contains embedded resources you can use the /OUT option. This will create a separate file for each embedded resource that you can the compare using your favourite diff tool, e.g. WinMerge:
```
ildasm /ALL /TEXT /OUT:folder1\dump.txt folder1\assembly.dll
ildasm /ALL /TEXT /OUT:folder2\dump.txt folder2\assembly.dll
```

回答3:

On the command line fc /b < oldfile > < newfile >

来源：https://stackoverflow.com/questions/3316505/how-can-i-know-if-an-assembly-really-did-change

标签

comparison

file-comparison