1 reply to this topic

[rcsdev]

We are trying to establish methods that will properly handle updates of file version resources in our binaries. Our product consists of hundreds of exe's and dll's generated from several platforms - .NET, Visual C++ 6.0, VB6.

It seems that to enable us to create relatively small patches, we do not want to increment any part of file version (e.g. build number) in some blind, automated fashion. I think that would cause any patch to include all files, even if they are not truly changed. Yet for a file with version resource that actually has changed, its version must be incremented if it is to be installed by the patch according to Windows Installer file versioning rules.

The dilemma is how to know that a file is being built because it is actually going to contain new code not just because objects are not available or we force a rebuild all. It is relatively obvious if the source for the given file has been modified, but not so obvious if outside dependencies change (i.e. a header or static library).

I have only been able to locate some pretty high level discussions of such matters (e.g. in Microsoft Patterns and Practices topics). In those they refer to methods to globally increment build number in the version resource (not what we want).

Has anyone dealt with this issue and/or come across any helpful info that would go into the real nitty gritty? Or have we miss-interpreted some key concept?

[luke_s]

It really depends on the situation. You will need to increment the build number if you executable changes (either its code or a libary code).

If there are minor changes, then you can just change one of the last version digits, if you have a major change, then you can increment the major number.

Maybe read about how install shield/Windows Installer recommends you version a msi package, and you can apply the same logic to your executable.