Over long time I used an automatic build incrementer add-in for Visual Studio and C++ projects, which proved to be helpful. Having increments in file information, the binaries were easy to identify. It was easy to find a matching symbol information etc. Long story short, a tool like this has been a must.
The add-in has problems or downsides though. It kept patching the .RC source and touched it when no other changes existed in the build, touching source code forced rebuilds on its own and reloaded resource-related files opened in Visual Studio editors. I was annoying even though more or less acceptable.
Visual Studio 2015 Community Edition does not support add-ins because of 2015 or because it’s Community Edition. Either way it was time to update the incrementer ot make things nicer overall.
This time I preferred to change things a bit. No longer source code patching: the incrementer can be attached as a post-build event and patch
VERSIONINFO resource on the built binary. This requires that current build number is kept somewhere but not in the .RC text, so I am using an additional .INI file. The good thing is that this file can still be included in version control system and the version history can be tracked relatively easily. No longer source code modification which makes code base dirty and forces another rebuild.
Command line syntax: C:\>IncrementBuild-Win32 Syntax: IncrementBuild-Win32.exe argument [argument...] Arguments: help - displays syntax configuration <path> - path to .INI file holding configuration information (mandatory) binary <path> - path to binary to be patched with file version update (mandatory) string <name> <value> - add, update or remove specific version information string (optional; multiple arguments possible) dump - print version information data block dump before and after update
Additional feature is that incrementer can attach additional version strings (see example below – it adds build configuration as a version information string).
Setting up is easy. First, the project should have a version information resource, so that the binary has data to patch in first place.
Then, there should be an .INI file which tracks version numbers. The binary will be build with .RC numbers and then incrementer will apply the least significant number from the .INI file incrementing it along the way.
[General] [VersionInformation] ;Language=133 ;MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US) ;Version String Format=%d.%d.%d.%d Current Build Number=4
Next thing, project post-build event needs a command for patching:
"$(AlaxInfo_Common)\..\Utilities\IncrementBuild\_Bin\IncrementBuild-$(PlatformName).exe" configuration "$(ProjectDir)Module.ini" binary "$(TargetPath)" string "ConfigurationName" "$(ConfigurationName)"
The command takes Module.ini from the projects directory for configuration file, patches build output and also attaches build configuration as an additional version information string.
Build output looks like this:
—— Rebuild All started: Project: EnumerateTransforms, Configuration: Release Win32 ——
Finished generating code
EnumerateTransforms.vcxproj -> D:\Projects…_Bin\Win32\Release\EnumerateTransforms.exe
EnumerateTransforms.vcxproj -> D:\Projects…_Bin\Win32\Release\EnumerateTransforms.pdb (Full PDB)
Configuration Path: D:\Projects…\Module.ini
Binary Path: D:\Projects…_Bin\Win32\Release\EnumerateTransforms.exe
Incrementing build number, product version 184.108.40.206, file version 220.127.116.11
Applying version information string, name “ConfigurationName”, value “Release”
Presumably, it is not necessary to use same bitness tool for a binary, since version information patching API should be able to patch resources of mismatching build, but I normally use a matching tool anyway, why not?