There are many solutions out there for automatic build number increment support. Many are meant for VC6. The ones I found for Visual C++ .NET are commonly using add-ins for the DevStudio. Usually, a good and very integrated method, they all have the disadvantage of inflexibility. They require some sort of separate header file with
defines that have to be used in the project's resource file. And if you want to adopt the add-in's functionality somehow to fit your needs more closely, it often is not possible to get the source code of the add-in.
So, I tried to find a macro for VC.NET instead of add-ins, unfortunately without success. That's the reason why I decided to write my own macro and offer it to the public. You can simply change it according to your needs, or take it as a template sample for your own macro implementations.
My macro implementation reacts on the DevStudio's event when a build starts. The macro scans resource files (.RC extension only) in all projects of the current solution. All files not having the extension .RC will be skipped.
In a resource file, the macro will search for all
VERSIONINFO definitions, and inside there, it will increment the build numbers for all 4 statements
FileVersion" and "
ProjectVersion". It will handle multiple language blocks, too (if present).
To disable parsing a .RC file, specify the following line of code somewhere in the .RC file:
If you don't specify this line or if it is remarked out, then the .RC file will be parsed and build numbers will be incremented.
DevStudio language related notes:
At the start of a build process, the
IncBuildNr macro will output information messages about success or failure of manipulating the .RC files or when .RC files have been skipped. The messages will be posted into the output-window's Build pane where the compiler inserts its own progress information, too. The macro is implemented for English versions of the DevStudio. If your DevStudio has a different language, it can be, that the macro does not find the correct output-window-pane. This can happen, because the macro simply opens a pane named "Build". If in your DevStudio, the output-window-pane for build progress information is named differently, it is recommended to change the pane name in the macro sources accordingly (in module
EnvironmentEvents, in function
Further description you can find in the macro sources themselves (when you open it in the DevStudio's Macro Editor).
First, go to the location of your Visual Studio macros. By default, this is Personal\Visual Studio Projects\VSMacros. In there, create a subdirectory named IncBuildNrMacro and copy the file IncBuildNrMacro.vsmacros in there.
Now, open the VC++ .NET DevStudio, open the Macro Explorer, right click on the root item "Macros", and select "Load Macro Project". Open IncBuildNrMacro.vsmacros. A warning appears informing you that the loaded macro contains event handling code. Select "Enable event handling code", and press OK. This is required, otherwise the macro would not react on build starts.
That's it. The next time you build a project, the
IncBuildNr macro will be invoked automatically.
In VC++ .NET DevStudio, go to the Macro Explorer, right click on "IncBuildNrMacro" and select "Unload Macro Project". You can delete the IncBuildNrMacro.vsmacros file now, if you like to.
Usage in your C++ project(s)
To query the
VERSIONINFO definition contents in your application at runtime, use
GetFileVersionInfo() and related functions.
All .RC files in all Projects of the current Solution will be handled at once. Even if the user wants to build only one specific project within the current solution, the macro will increment build numbers of all the projects in the solution. I did not find a way (yet) to detect which projects are being compiled. Although this can be seen as a drawback, it can also be seen as an advantage: all the build numbers in the projects will be handled always at the same time. So, the build numbers remain accurate and equal over all projects.
But nevertheless, if you find a way to detect specific projects being built, let me know.
Further, whenever a project's resources have been opened in the DevStudio either in the Resource View (the tree view) or in resource editing windows such as the dialog editor, the icon editor etc., the macro first will close all these windows so that it can access the contents of the resource file. (Exception: the Resource View Tool window will stay present.) It may be annoying to see all the resource windows disappear every time a build process is started. But again, I did not find any other solution for this problem yet. Maybe you have a better idea. If so, please let me know.
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.