Visual Studio with SubWCRev auto-build versioning problem

Question

Folks,

I'm using VS2010 and trying to sync the build version of my project with my Subversion repository using SubWCRev. This is all working correctly, but I can't quite get my head around one thing. My template file consists of this :

#define MAJOR_VERSION       2
#define MINOR_VERSION       2
#define MICRO_VERSION       0
#define BUILD_VERSION       $WCMODS?$WCREV$+1:$WCREV$$

#define QUOTE_(x) #x
#define QUOTE(x) QUOTE_(x)

#define BUILD_VERSION_STRING    QUOTE(MAJOR_VERSION.MINOR_VERSION.MICRO_VERSION.BUILD_VERSION)

Then in my application .RC file I have :

 FILEVERSION MAJOR_VERSION,MINOR_VERSION,MICRO_VERSION,BUILD_VERSION
 PRODUCTVERSION MAJOR_VERSION,MINOR_VERSION,MICRO_VERSION,BUILD_VERSION
 FILEFLAGSMASK 0x17L
#ifdef _DEBUG
 FILEFLAGS 0x1L
#else
 FILEFLAGS 0x0L
#endif
 FILEOS 0x4L
 FILETYPE 0x1L
 FILESUBTYPE 0x0L
BEGIN
    BLOCK "StringFileInfo"
    BEGIN
        BLOCK "080004e4"
        BEGIN
            VALUE "FileVersion", BUILD_VERSION_STRING
            VALUE "ProductVersion", BUILD_VERSION_STRING
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x800, 1252
    END
END

As you can probably work out, I'm trying to up the build version by 1 if there's modified code so that the build version in the EXE will match the Subversion revision number when I do a release and check the code in. The problem is that BUILD_VERSION gets expanded to x+1 or x+0 which then appears in the BUILD_VERSION_STRING as "2.2.0.227+1" which is not quite what I intended.

Does anyone with a little more experience with this know a way to achieve my aim? Thanks in advance

score 2 · Answer 1 · answered Jan 23 '14 at 12:07

2

#define BUILD_VERSION       $WCMODS?$WCREV+1$:$WCREV$$

answered Jan 23 '14 at 12:07

Markus Jarderot

86,735
21
136
138

PhilMY · Answer 2 · 2012-06-18T08:35:55.947

1

If you use subwcrev to generate an unversioned header from your versioned template, then #include the unversioned header in your versioned .RC file, you can build for release from an unmodified work area.

Then you can just use

#define BUILD_VERSION       $WCREV$

This also removes the risk of any changes creeping in between building your release EXE and checking in the code.

edited Jun 18 '12 at 08:35

answered Jun 13 '12 at 14:30

PhilMY

2,621
21
29

Yes, that's exactly what I was doing. The problem/annoyance in doing this is that if you check the code in, then do the build for release, then the very act of doing the build modifies the .rc file and marks it as modified because BUILD_VERSION has changed. This was a problem I had a while ago and I never really figured out a satisfactory solution. I guess you just have to decide which way to work and stick to it and the quirks that come with it - either build first, then check in or check in first, then build. – Redeye Jun 18 '12 at 07:55
1

I put `#include "buildversion.h"` in the RC file – PhilMY Jun 18 '12 at 08:31

score 1 · Answer 3 · answered Mar 31 '11 at 17:18

Im my group we only automate the update of the least significant value with the svn revision number for the projects working directory. To do this we have added a pre-build step to each project that creates and then calls a batch script that does the following:

Copy $(ProjectDir)Properties\AssemblyInfo.cs to $(ProjectDir)Properties\AssemblyInfo.cs.template.
Find AssemblyVersion("X.Y.Z.ddd") in $(ProjectDir)Properties\AssemblyInfo.cs.template and replace with AssemblyVersion("X.Y.Z.$WCREV$").
Find AssemblyFileVersion("X.Y.Z.ddd") in $(ProjectDir)Properties\AssemblyInfo.cs.template and replace with AssemblyFileVersion("X.Y.Z.$WCREV$").
Run 'SubWCRev $(ProjectDir) $(ProjectDir)Properties\AssemblyInfo.cs.template $(ProjectDir)Properties\AssemblyInfo.cs'

Nick · Answer 4 · 2011-03-29T08:04:51.250

0

Could you do something like:

#define MOD_VERSION $WCMODS?1:0$
#define REVISION $WCREV$
#define BUILD_VERSION ( REVISION + MOD_VERSION )

Edit: This won't work either as pointed out in the comments!

What is the purpose of your version number? If it's to get back to the source code used to produce the binary then you might be shooting yourself in the foot a bit here. What happens if someone checks some more code into the repository at the same time as you're creating your version number? You're going to end up with your binary referencing different code.

What might be better would be to check to see if the working copy has any modifications or mixed revisions and use a specific revision number (e.g. 0xFFFFFFFF or 0) to represent this. And only use the true revision number if you used a clean tree to build the binary.

#define MAJOR_VERSION       2
#define MINOR_VERSION       2
#define MICRO_VERSION       0
#if $WCMODS?1:0$
#define BUILD_VERSION       0
#else
#define BUILD_VERSION       $WCREV$
#endif

edited Mar 29 '11 at 08:04

answered Mar 28 '11 at 15:20

Nick

25,026
7
51
83

That does exactly the same thing because it expands the macro, but doesn't evaluate it so my BUILD_VERSION_STRING becomes "2.2.0.( 227 + 1 )". – Redeye Mar 28 '11 at 15:33
Yeah you're right. I'm not sure there's any way to evaluate preprocessor calculations at compile time. You might need to use a global variable if that's possible. – Nick Mar 29 '11 at 07:57
Thanks for your help Nick. The reason I want to do this is that there's only ever going to be me working on this project, so there's no danger of anyone else messing things up doing a check in. I have a routine that I follow religously for doing releases - build EXE, build installer, check code in. By doing this, I can always get back to the code that produced a release by reverting to that revision. Maybe not the best way in the world, but there you go. – Redeye Mar 29 '11 at 08:25

Visual Studio with SubWCRev auto-build versioning problem

4 Answers4