Synchronized Enterprise File Versions

• Download VS2008 source - 45.1 KB
• Download VS2003 .NET source - 55.8 KB

Introduction - Why Yet Another Version Counter?

Proper installation of enterprise apps requires accurate file versions. This can become quite complex for a large numbers of apps, and synchronization of build numbers can help reduce this complexity.

Build number identification of apps (for feature tracking, bug tracking, customer patches, QA testing, etc.) can be made manageable by synchronization of build numbers across an entire suite.

However, manually synchronizing all the file versions and product versions of a very large suite of applications can be a time-consuming and error-prone task. It is preferable to do this in an automated fashion, with as few failure points as possible. And when manual changes are unavoidable, it is preferable to change the version numbers in only one place.

Several excellent how-to solutions exist on the Internet for single-app automated version advancement, and I am not attempting to duplicate those. This how-to is specifically geared for large suites of C++, C#, and VB apps that are built by an automated process (e.g., a nightly build performed by a tool, such as CruiseControl).

Note: This is a beginner-level article.

If my explanation below seems a little pedantic, please understand that I am attempting to make this fairly thorough, in order to address multiple skill levels. I am hoping to answer as many questions as possible before they come up, by including, in excruciating detail, the steps that I actually performed to make this running / working project.

The development tool I have used for the solution outlined here is Visual Studio 2008. I have done something similar with Visual Studio .NET 2003, with only a few subtle differences. A solution is implemented in three languages in this article: C++, C#, and VB.

For convenience sake (and in the spirit of attempting to make life easier for folks of all skill levels), a second solution is available in the VS 2003 zip file at the top of this article. See the ReadmeVS2003.pdf in the zip file for an abbreviated explanation of the minor differences between the two solutions. I hope to edit this article periodically and add other VS versions as I get time and access to them. Earlier versions such as VS 6.0 would, of course, only support C++, and possibly VB.

Creating the Base Project

In this demo:

• I create a blank project
• I add C# file version support
• I add C++ version support
• I add VB version support hack, and then
• I add simple batch version updates (implemented in DOS, for the sake of simplicity) to the compile process

The first step is to create a blank project.

Creating C# Version Support and a Sample App

Version support is implemented as a C# Library project.

My wizard pre-created a stubbed out Class1.cs. We will reuse this to implement our automated C# version. Add the const String from Figure 3 to Class1.cs.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MyCSharpVersion
{
    public class Class1
    {
        public const String MyCurrentVersionNumber = "1.2.3.4";
    }
}

For the sake of completeness, we use this class to update the file and product versions of the C# version library itself. Edit the code in the library assembly info. In VC Studio 2008, you can find that under Properties.

Caveat: In this project, there will be two C# assembly info files, one for the C# version library and one for the sample C# app that uses it. This is the former.

Enter the code in Figure 5 to access the version number at compile time.

Note: You will be adding only one line from Figure 5 and editing one other line. The rest are included so that you can find the places to insert/edit the code.

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
using MyCSharpVersion;
.
.
.
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyFileVersion(MyCSharpVersion.Class1.MyCurrentVersionNumber)]

Compile the library project, and open Windows file explorer in the folder that contains the compiled DLL. You may need to change the View to “details.” Right-click on the column headers in Details view in order to display the two new columns. Select “more…”. Check the “file version” and “product version” checkboxes.

Your display should now look something like Figure 7.

Warning: The file version displayed here will not necessarily match the file version you get by right-clicking the DLL and viewing the Version tab.

As we should see in the C++ example, the file version displayed by file explorer is an integer embedded in the binary, while the file version displayed by the Properties dialog is a string resource (also embedded in the binary). The product version displayed in Windows file explorer, on the other hand, is one and the same as the product version displayed in the Properties dialog.

Next, we create a sample C# version app that uses the version library project.

This app will also have an assembly info file. Open it and add the same code that you did to the first assembly info file (see Figure 5). The difference this time is that you will also need to add a reference in your new C# app’s project to the C# version library.

Now, compile the project and view the file and product version of the new C# sample app executable, using a similar technique to Figure 6 and Figure 7.

Creating C++ Version Support and a Sample App

To implement version control for C++, we need to create a set of header and source files. We can add this to the blank project that we created in the first part of this demo. First, we need a header that contains the macros we need to merge the version info into our resource file (shown in Figure 19).

Insert the set of macros in Figure 12 into the header.

#ifndef STRINGER
#define STRINGER( x ) #x
#endif
#ifndef RESTRINGER
#define RESTRINGER( x ) STRINGER( x )
#endif

#define MY_BUILD_FILE_NUMBER( rel, svcpk, minver, build ) \
 RESTRINGER(rel) "." RESTRINGER(minver) "." RESTRINGER(svcpk) "." \
 RESTRINGER(build) "\0"
#define MY_BUILD_PROD_NUMBER( rel, svcpk, minver, build ) \
 RESTRINGER(rel) "." RESTRINGER(minver) "." RESTRINGER(svcpk) "." \
 RESTRINGER(build) "\0"

#include "MyVersionNumber.h"

Add a header for the version numbers themselves.

Insert the code for the version numbers from Figure 14. If you alter these names, you must also change them in the resource files that use them (shown in Figure 19).

#define MY_RELEASE_NUMBER       5
#define MY_SERVICE_PACK_NUMBER  4
#define MY_MINOR_VERSION_NUMBER 3
#define MY_BUILD_NUMBER         210

To make this compile without errors under VC 2008, we also need a dummy source file.

Add some code to make it compile. You may be creative if you wish. Figure 16 has something that will work.

void main()
{
    return;
}

Now, we need to add the C++ app that will use this header info. This time, for the sake of variety, we will make a Win32 app.

Edit the resource file that the C++ wizard created. This will typically have a .rc or a .rc2 extension. For some projects, no resource file is created by the VC wizards. In those cases, you will have to add your own resource file. The step of adding your own resource file is not shown here.

Edit the resource file you chose, using text mode. Here, I chose to edit WindowsApplication2.rc.

If the resource file you selected does not already have a VS_VERSION_INFO block, you need to add one; otherwise, just edit the existing VS_VERSION_INFO block. The important sections of code in Figure 18 have references to file version and product version. There are four lines in all (containing "FILEVERSION", "PRODUCTVERSION", "FileVersion", and "ProductVersion").

#include "..\VersionTest\MyVersionHeader.h"

VS_VERSION_INFO VERSIONINFO
 FILEVERSION MY_RELEASE_NUMBER,MY_SERVICE_PACK_NUMBER,
     MY_MINOR_VERSION_NUMBER,MY_BUILD_NUMBER
 PRODUCTVERSION MY_RELEASE_NUMBER,MY_SERVICE_PACK_NUMBER,
     MY_MINOR_VERSION_NUMBER,MY_BUILD_NUMBER
 FILEFLAGSMASK VS_FF_DEBUG
 FILEFLAGS 0x0L
 FILEOS VOS_NT_WINDOWS32
 FILETYPE VFT_APP
 FILESUBTYPE VFT2_UNKNOWN
BEGIN
    BLOCK "StringFileInfo"
    BEGIN
        BLOCK "040904B0"    // concatenation of US-English, Unicode
        BEGIN
            VALUE "Comments", "Prototype Version Auto Info\0"
            VALUE "CompanyName","My Company\0"
            VALUE "FileDescription", "Version Prototype\0"
            VALUE "FileVersion", MY_BUILD_FILE_NUMBER(MY_RELEASE_NUMBER, 
                  MY_MINOR_VERSION_NUMBER,MY_SERVICE_PACK_NUMBER,MY_BUILD_NUMBER)
            VALUE "InternalName", "Version Prototype\0"
            VALUE "LegalCopyright","Copyright © My Company 2009\0"
            VALUE "LegalTrademarks","My Trademark\0"
            VALUE "OriginalFilename", "versionautoinfo.exe\0"
            VALUE "PrivateBuild", "\0"
            VALUE "ProductName", "Version Prototype\0"
            VALUE "ProductVersion", 
                  MY_BUILD_PROD_NUMBER(MY_RELEASE_NUMBER, 
                  MY_MINOR_VERSION_NUMBER,MY_SERVICE_PACK_NUMBER,MY_BUILD_NUMBER)
            VALUE "SpecialBuild", "\0"
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x409, 1200  // US-English, Unicode
    END
END

Before you compile, add the VersionTest project folder to your #include path.

Now, compile, and check the file and product versions, as you did in Figure 6 and 7.

Creating Visual Basic Version Support and a Sample App

My VB support for automatic versioning is (I suspect) a hack, which actually, in a spooky sort of way, looks a whole lot like the C# solution. It involves editing the assembly info file. I'm sure there are dire and dreadful warnings about violating the crypt of the VB assembly info text file, but I tend to be very pragmatic and little bit of a cowboy when it comes to software development... Maybe there are some VB gurus out there (I'm certainly not one of them) that can shed more light and give some sound advice on this.

So! All that being said, use this technique at your own risk!

As we did for C#, create a VB Library project.

In the Class1 class that my wizard automagically created for me, we put in the const string, very much like we did for C#.

Public Class Class1
    Public Const MyCurrentVersionNumber = "11.0.0.20"
End Class

This time, for the sake of variety, let's add a VB Windows service.

Now comes the hack part. Close the solution! Then, edit the VB library assembly info thus, from Start + Run.

notepad C:\VersionTest\MyVisualBasicVersion\My Project\AssemblyInfo.vb

Edit the line below in your library assembly info file that contains AssemblyFileVersion.

' You can specify all the values or you can default the Build and Revision Numbers 
' by using the '*' as shown below:
' <Assembly: AssemblyVersion("1.0.*")> 
<Assembly: AssemblyVersion("1.0.0.0")> 
<Assembly: AssemblyFileVersion(Class1.MyCurrentVersionNumber)>

Now edit the VB service assembly in a similar way, but note the extra "Imports" line with this one.

notepad C:\VersionTest\WindowsService3\My Project\AssemblyInfo.vb

Imports System
Imports System.Reflection
Imports System.Runtime.InteropServices
Imports MyVisualBasicVersion
.
.
.
' You can specify all the values or you can default the Build and Revision Numbers 
' by using the '*' as shown below:
' <Assembly: AssemblyVersion("1.0.*")> 
<Assembly: AssemblyVersion("1.0.0.0")> 
<Assembly: AssemblyFileVersion(Class1.MyCurrentVersionNumber)>

Now restart, and add the library to your Windows Service.

Compile, and check the VB file and product versions, as you did in Figure 6 and 7.

Automating the Version Updates for Each Build

The final step to make this work in a batch environment is to add the version increment mechanism to the build process. This can be done in a number of ways, such as Apache Ant, Cygwin bash scripts, AWK, Perl, Python, or a host of other scripting and automated utilities. My demo uses DOS batch commands, for the sake of simplicity.

Create a “seed” version control file with your initial versions and build number in it. For instance, use notepad.exe to create a file named C:\VersionTest\BUILDINFO.TXT, and insert the text in Figure 29.

MAJORVERSION=2 
MINORVERSION=3 
SERVICEPACK=4 
BUILDNUMBER=19

Again, use notepad.exe to create a batch file named MYBUILD.BAT, and insert the text in Figure 30.

Note: In this demo, it is assumed that this batch file and the BUILDINFO.TXT version info file have been created in C:\VersionTest.

@ECHO ON
REM (DV) THIS HAS BEEN TESTED ON WINDOWS XP USING VS.NET-2003 AND VS-2008
CALL "C:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\vsvars32.bat"
SET LOGNAME=MYBUILD.LOG
SET BUILDINFOFILE=BUILDINFO.TXT
SET BUILDDRIVE=C:
SET BUILDROOT=%BUILDDRIVE%\VersionTest
REM Yes, I did mean to use "VersionTest" again in CPPHEADER :)
SET CPPHEADER=%BUILDROOT%\VersionTest\MyVersionNumber.h
SET CSHARPCLASS=%BUILDROOT%\MyCSharpVersion\Class1.cs
SET VBCLASS=%BUILDROOT%\MyVisualBasicVersion\Class1.vb
SET MAJORVERSION=0
SET MINORVERSION=0
SET SERVICEPACK=0
SET BUILDNUMBER=0
%BUILDDRIVE%
CD %BUILDROOT%

FOR /F %%I IN (%BUILDINFOFILE%) DO SET %%I

ECHO MAJOR VERSION = %MAJORVERSION%
ECHO MINOR VERSION = %MINORVERSION%
ECHO SERVICE PACK  = %SERVICEPACK%
ECHO BUILD NUMBER  = %BUILDNUMBER%

SET /A BUILDNUMBER=%BUILDNUMBER% +1

ECHO NEW BUILD NUMBER = %BUILDNUMBER%

ECHO MAJORVERSION=%MAJORVERSION% > %BUILDINFOFILE%
ECHO MINORVERSION=%MINORVERSION% >> %BUILDINFOFILE%
ECHO SERVICEPACK=%SERVICEPACK% >> %BUILDINFOFILE%
ECHO BUILDNUMBER=%BUILDNUMBER% >> %BUILDINFOFILE%

ECHO #define MY_RELEASE_NUMBER %MAJORVERSION% > %CPPHEADER%
ECHO #define MY_MINOR_VERSION_NUMBER %MINORVERSION% >> %CPPHEADER%
ECHO #define MY_SERVICE_PACK_NUMBER %SERVICEPACK% >> %CPPHEADER%
ECHO #define MY_BUILD_NUMBER %BUILDNUMBER% >> %CPPHEADER%

ECHO using System; > %CSHARPCLASS%
ECHO using System.Collections.Generic; >> %CSHARPCLASS%
ECHO using System.Linq; >> %CSHARPCLASS%
ECHO using System.Text; >> %CSHARPCLASS%
ECHO namespace MyCSharpVersion >> %CSHARPCLASS%
ECHO { >> %CSHARPCLASS%
ECHO public class Class1 >> %CSHARPCLASS%
ECHO { >> %CSHARPCLASS%
ECHO public const String MyCurrentVersionNumber = 
       "%MAJORVERSION%.%MINORVERSION%.%SERVICEPACK%.%BUILDNUMBER%"; >> %CSHARPCLASS%
ECHO } >> %CSHARPCLASS%
ECHO } >> %CSHARPCLASS%

ECHO Public Class Class1 > %VBCLASS%
ECHO Public Const MyCurrentVersionNumber = 
      "%MAJORVERSION%.%MINORVERSION%.%SERVICEPACK%.%BUILDNUMBER%" >> %VBCLASS%
ECHO End Class >> %VBCLASS%

TYPE %BUILDINFOFILE%
TYPE %CSHARPCLASS%
TYPE %CPPHEADER%
TYPE %VBCLASS%

CALL devenv VersionTest.sln /clean Release /out %LOGNAME%
CALL devenv VersionTest.sln /build Release /out %LOGNAME%

This batch file updates the version info control file with the latest build number, and then creates three version files, one for the C++ projects, one for the C# projects, and one for the VB projects. It then builds the projects using the devenv compiler.

Warning: If your source code control fiddles with the read-only bits on your source code files, you will need to add commands to either clear the read-only bit before you write your C# and C++ files (e.g., the ATTRIB command) or just force-delete them (i.e., DEL /F).

To run this:

C:\> CD VersionTest
C:\VersionTest\> MYBUILD.BAT

Check the file versions using the approach in Figures 6 and 7 above. Each time you run the build batch file, you should see the build version odometer tick up one number.

Final Comments

As with most of this project, there are many other ways that this last step could have been implemented. I recommend that you choose whatever is most compatible with your current build environment.

This solution is designed strictly to be run as a batch process. In my environment, it is unnecessary (in fact, undesirable) to update the build number every time the solution is built from the VS IDE. This is usually the case when there is simultaneous development on the same code/apps, especially where formal source code control is employed. However, other environments may require version numbers to roll every time a build is run. Keep these factors in mind when you are deciding whether to include build increments as a pre-build step (not shown here) or as a batch process.

History

• 11/17/2009 - Added working sample for VS 2003 .NET.
• 11/20/2009 - Added VB hack to both VS 2008 and VS 2003 .NET.