Every time we recompile our C# application we end up with EXEs with different MD5 signatures. We are recompiling on the same machine, minutes apart. Why doesn't the same source-code yield the same output? Is there a way to fix this?
问题:
回答1:
"So every assembly has:
- A Timestamp, in two locations
- A GUID that matched the PDB
- What appears to be a completely random GUID generated every compile.
- A counter indicating what the build of the assembly is - generated only in subsequent Visual Studio builds."
from:
http://ritter.vg/#code_adventures_clr1
回答2:
I think the key there might be "minutes apart". If there is a timestamp within the EXE, then that would alter the MD5 signature.
回答3:
I've had to dissect these cases before and it appears to just be DateTime-stamp type changes (it's a guess). If you put both assemblies under diff tools you'll see only a very small number of lines in the PE have changed; if you change even a small amount of code and compare assemblies you'll see drastically larger differences.
Here's a question I opened while researching tools to identify "real" differences from superficial ones:
.NET Assembly Diff / Compare Tool - What’s available?
回答4:
Most likely you have several *'s in the version number of the assembly. This causes the assembly version number to be auto-incremented on build which will cause a visible difference in the outputted assembly. Hence a different MD5 checksum.
Try switching the version number to a constant assembly version and see if that fixes the issue.
回答5:
You could try running ildasm.exe (my path for this is C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin
) on the two .exes.
Then dump out the raw view of the headers, and compare them with a diff tool. If there is still no difference, then it might be the PE headers which would need a more advanced tool to discover. Ildasm gives you the PE header size and other statistics on it though.
回答6:
There will be a built in version number that will change with every build.