4

I am using MS Visual Studio 2008 to do some development work in C++ and currently we have a version function that returns a hard coded string representing the version number. I would like to figure out a way so that instead of a hard coded number, it could start from, say, 1 and increment by 1 every time I make a debug or release build (or even better, keep track of the debug version and release version numbers). Or if that is not possible, use the current date/time as the version number.

Note that because there will be several people working on the project and using the SVN, the code has to be computer independent (meaning that if I am currently on version 100, my colleague's last build was at version 90, then the next time (after I check in the code and my colleague pulls out the code), the version number of his next compile should be 101 rather than 91.)

Could you please help?

Paolo
  • 20,112
  • 21
  • 72
  • 113
AZhu
  • 1,312
  • 6
  • 22
  • 40
  • 4
    Some folk use the SVN version number to do this. – Bathsheba Jan 02 '14 at 15:21
  • 1
    If you have some server which do daily builds, you can make it commit on each build new build number. It can be a script that will be incrementing some value in ie. version.cpp file. – marcinj Jan 02 '14 at 15:27
  • @Bathsheba any details on how it could be implemented? – AZhu Jan 02 '14 at 15:28
  • 1
    Related: http://stackoverflow.com/questions/2328724/how-can-i-store-the-new-svn-revision-number-in-my-source-code-after-i-commit-t – arne Jan 02 '14 at 15:31
  • 1
    Doesn't Visual Studio have settings to set the version number (including autoincrement) when you publish the application? – Brian S Jan 02 '14 at 15:41

2 Answers2

8

If you are using TortoiseSVN you can use subwcrev.exe in a pre build event to write the current revision number to a source file.

Therefore, checkin a file version.template.hpp and add something like

  const string version = "13.12.0.$WCREV$";

Add a project pre build event

subwcrev.exe "$(SolutionDir)." "$(ProjectDir)version.template.hpp" 
             "$(ProjectDir)version.hpp"

and include the generated file #include "version.hpp".

hansmaad
  • 18,417
  • 9
  • 53
  • 94
  • This is what we actually use however how does that exactly work? Do I need to make changes, check in the code, get the version number, check out the code and then compile the program? – AZhu Jan 02 '14 at 15:33
  • 1
    @Bathsheba We use this as additional number in a version like `14.01.01.10345` where 14.01.01 is the 1st January release of 2014 and is edited manually before deployment. Users don't care about 10345... – hansmaad Jan 02 '14 at 15:33
  • 1
    @AZhu subwcrev.exe uses the rev of the working copy. The number doesn't change on every build but on every commit. See edit... – hansmaad Jan 02 '14 at 15:45
  • 1
    Instead of keeping the version in the sources, I wanted to see the version in the .exe properties (a quicker way). So instead of generating the "version.hpp" file, I generated the "Project.rc" file (pr whatever name has a project's RC file), in which I put the SVN revision in the version field, and everything works fine. – reallynice Oct 28 '15 at 09:35
2

If you want to do things automatically when you build a solution (either debug, release or both), Visual Studio has custom build events/steps which you can use to fire off a program or script to do whatever you want. The answer by hansmaad maybe isn't exactly what you want because there is no "auto-increment for each build", rather I assume the idea is to put SVN's version number of some file into a source file that gets compiled in. This makes sense to me because it allows you to tie a build to some source snapshot in SVN.

I think merging these two ideas (auto build increment and source controlled version file) is a little problematic... what happens when two developers start with version X and both build and update the version to X+1? Which one should take precedence when committing. I suppose it would be however committed their changes last, but that doesn't necessary carry any meaning, in my opinion. In other words, version Y on my machine is not the same as version Y on my co-workers machine.

It makes more sense to me to have a release process that marks the build with an auto-incrementing version, rather than have it auto-increment for every developer's build.

Aaron
  • 594
  • 2
  • 12