Question

The version information, displayed when the mouse cursor hovers over the file in windows explorer, is set for a file built by visual studio in the VERSION resource. I would like to set the version in one place for all the files built by a solution, preferably when I change the version in the install properties. Is there a way to do this?

The motivation for this is that if the version is not updated for a file, then the installer will leave previous versions of files instead of replacing them with new files. This happens even when the 'RemovePreviousVersions' property is set. In order to save the tedious and error prone task of updating the version in every file built and installed, I remove the version resource from all files - which is not elegant.

Was it helpful?

Solution

The second answer in Stack Overflow topic How to programatically change a project's product version? features a solution for setting the version number from a common header file in C++. Just place the header file containing the hard-coded version numbers in a folder where each project can find it.

The above answer also describes a means of incrementing the version number. An alternate approach for C++ version incrementing is available from Microsoft's article How to increment version information after each build in Visual C++.

Alternately, you can use your source control repository revision number as part of the version number. The Stack Overflow article Creating a file with build number and branch name in SVN gives some insight into this for TortoiseSVN users. The following two articles explore this in more depth:

Integrating the Subversion Revision into the Version Automatically with .NET (C# or VB)

Integrating the Subversion Revision into the Version Automatically with Native C/C++

(the above two web pages feature links to similar procedures for TortoiseHg users)

In theory, you could have a single text file holding the new version number, then run a pre-build script that would:

  1. Increment the version number in the text file (optionally incorporating a repository revision number)
  2. Write out or modify common version files for:
    • C++ (version.h)
    • C# (GlobalAssemblyInfo.cs)
    • Java (by way of an Ant properties file, e.g. version.properties)
    • etc.

OTHER TIPS

To centralize versioning for a solution:

  1. Take the version info out of AssemblyInfo.cs;
  2. Create a new file (GlobalAssemblyInfo.cs) and put your version info in it (using * to get VS to create a new version number for each build);
  3. Reference GlobalAssemblyInfo.cs as a link: Add | Existing Item then drop down the Add button in file selection to choose Add as Link instead;
  4. Repeat for each project in the solution;

I use a block like this for the version:

#if DEBUG

[assembly: AssemblyVersion("1.8.0.0")]

#else

[assembly: AssemblyVersion("1.8.*")]

#endif

This keeps VS from rebuilding every assembly during development, but gives every assembly a new version number when I build a release.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top