DLL Versioning

[trailway]

I want to begin doing incremental builds and start delivering Microsoft Patches (msp files) to my customers. One of the keys to making patches work is that the version number on the DLLs has to be incremented. I know that Visual Build has a nice capability to increment the version only if a build is otherwise required. Cool.

The version numbers are typically 4 digits, Major.Minor.Revision.Build. Normally, I would want to increment the 4th digit. If I have to deliver a build with only changes in the 4th digit then I would call this a hot fix.

When I have a set of fixes that I want to package into a Revision (or Service Pack) then what I want to do is to increment the 3rd digit the first time a DLL rebuild is required and then start incrementing the 4th digit.

For example let’s say that the DLL version is 1.2.3.4.
The next time it requires a rebuild it goes to 1.2.3.5, then 1.2.3.6, and so on.
If I decided to make a set of changes I am going to call a service pack then the next time it requires a rebuild, if any, it should go to 1.2.4.0, then 1.2.4.1, and so on.

Is this non-standard? I really just want to adopt standard best-practices.

Of course, I can just change the version number of all DLLs when I start a Service Pack but that touches every DLL, bloats the patch, and causes my customer to be concerned about the extent of the changes required.

FWIW, I have VB 6.0, VS 6.0 C++, VS 2008 C#, and VS 2008 VB.NET projects.

[kinook]

I don't know if there is a single standard for that. What we do is always increment the 4th number for patches, otherwise explicitly set the version to a particular value (i.e., 1.2.0.0 or 2.0.0.0) when releasing a new minor or major update.

You can use field overrides to dynamically determine the value of the Increment/Set and 3rd/4th field options on the Make VC6 and Make VS 2008 actions.
http://www.kinook.com/VisBuildPro/Manual/actionfieldoverride.htm

VB6 is more of a pain since it only allows you to update the first, second, and fourth version values. To update the third value, you need to update the executable's version resource after building.
http://www.codeguru.com/tools/standalonetools/article.php/c1403

[trailway]

Good feedback.

I appreciate it!

[DuncanL]

VB6 is more of a pain since it only allows you to update the first, second, and fourth version values. To update the third value, you need to update the executable's version resource after building.[/B]
There is another solution, which we are using in our build process: vbAdvance (click to go to the site - Kinook, why are links on this site the same colour as text?! :) ) (http://vb.mvps.org/tools/vbAdvance/) allows you to build VB6 projects with a give four part version number.

I use a subroutine to write the revision number into the project file with WriteINI, prior to building it with the standard VB6 build step with the version number set as VB expects (Major.Minor.Build). I then replaced my VB6 build steps with calls to this subroutine.

The final files then have "Major.Minor.Revision.Build" format versions.

[trailway]

Thanks for the link Duncan. I appreciate that.

Since my original post I have come up with an approach that I want to try. What I want to do is to write custom code which determines what the version number should be if a given component has to be rebuilt. I then want to modify the version information file to be this version but do so in a way that touchs the file back using it's orginal time stamp, i.e. pretend as if I did not make the change. I then do a dependency build. If the component builds then it gets the new version. If it does not then it keeps what ever version it has.