views:

57

answers:

2

Hi,

I'm trying to work with an existing home grown implementation of click-once. Currently we manually update the manifest for assemblies that we actually changed. I'm attempting to make it automatic based on a binary comparison of the existing assemblies and the newly built assemblies. Unfortunately, it seems that each time I run clean + build (automated build script) there are small differences to the assemblies, essentially invalidating the use of our click-once solution at all. I'm guessing that these differences are caused by some sort of guid generation or something along those lines. Is there anyway to prevent the differences in the assemblies?

And unfortunately, due to our branching/CI strategy I don't have the option of not cleaning because each release is from a new branch.

Otherwise, any suggestions on how I can compare two assemblies to see if any code has changed, without having access to the source code.

Thanks,

David

A: 

Typically, autobuild systems check the filesystem timestamps of the binary vs the source files (or object files vs source files, depending on the language). If the source is newer than the binary/object, a rebuild is triggered. This strategy may work better for you instead of actually diffing binaries/

cyberconte
No dice. The buildserver builds the assemblies from scratch, zips them, then we deploy the zip onto our prod server. The creation time stamp is whenever the assemblies are built.
David
A: 

I found BitDiffer a tool from www.BitWidgets.com that compares what has changed in an assembly. While this runs slower than a binary comparison, it removes the need to have MSBuild create an identical assembly.

Thanks,

David

David