Question

Background:

I have been charged with trying to come up with a new way to compare dlls and exes that use AssemblyInfo to embed a version number. Every time we do a new build, the version gets incremented accordingly. However, when it comes time to deploy the new version, we only want to copy dlls and exes that have actually changed, but the embedded version number makes it seem like this is always the case.

To get around this, the system currently just relied on comparing the filesize, but my task has arisen from noticing this doesn’t appear to be good enough since we had a failure to deploy a new exe despite the fact it changed; they just happen to have the same filesize. We don’t know how often this is happening, so we need to do something about it, but if possible we’d like to still be smart about replacing the dlls and exes so users aren’t forced to shut the UI down every time we really only need to replace files the UI doesn’t use.

My question, therefore, is whether there is a clever way to compare exes and dlls with embedded versions from use of AssemblyInfo while ignoring that metadata itself. The more I’ve looked around the more it seems like this probably isn’t possible, but I thought it was worth asking before giving up and switching to replacing everything every time.

Appreciate the help!

Edit: I suppose one thing I was really hoping would be possible is doing a bitwise comparison with certain offsets. Does AssemblyInfo always compile in at a particular point, such as being a header or footer of sorts that can be accounted for in the comparison?

Answer 1

Eric Lippert has already covered this:

Is compiling the same C# program twice guaranteed to produce the same binary output?
No.
Well, that was an easy blog to write.
…
The C# compiler by design never produces the same binary twice. The C# compiler embeds a freshly generated GUID in every assembly, every time you run it, thereby ensuring that no two assemblies are ever bit-for-bit identical