Kinook Software Forum

Go Back   Kinook Software Forum > Visual Build Professional > [VBP] General Discussion

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 08-24-2009, 03:19 PM
trailway trailway is online now
Registered User
 
Join Date: 04-07-2009
Posts: 26
DLL Versioning

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.
Reply With Quote
  #2  
Old 08-24-2009, 03:35 PM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,003
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/Ma...ldoverride.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/standa...icle.php/c1403
Reply With Quote
  #3  
Old 08-24-2009, 03:40 PM
trailway trailway is online now
Registered User
 
Join Date: 04-07-2009
Posts: 26
Good feedback.

I appreciate it!
Reply With Quote
  #4  
Old 08-28-2009, 06:34 AM
DuncanL DuncanL is offline
Registered User
 
Join Date: 07-26-2007
Posts: 29
Quote:
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?! ) 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.
Reply With Quote
  #5  
Old 09-04-2009, 09:02 AM
trailway trailway is online now
Registered User
 
Join Date: 04-07-2009
Posts: 26
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.
Reply With Quote
Reply

Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 06:50 PM.


Copyright © 1999-2023 Kinook Software, Inc.