Programmatically Changing Build Version

Question

We are wanting to automate our build process and we have a particular problem. We have been looking into the Jenkins tool and quite possibly, LabVIEW 2011 may help us out when we upgrade, not sure though.  But before we look outside of LabVIEW for a solution, we want to run this dilemna by some of the LabVIEW users. We are using the Unit Test Framework and let's say we have some unit tests in our project. We wrote a wrapper VI that will do the following:
1) progammatically execute the unit tests using the Run Tests from File.vi.
2) unbundle the test status from the output cluster array and look for a "Passed" result
3) if the result is indeed "Passed" then this means that the overall results for the unit tests are OK and go ahead and call the Build Targets Programmatically.vi with the appropriate path, name of build and target. The name of the build is set in the properties of the build specification in the project.
This works fine. What we want is the ability to either auto-increment the version number (which the checkbox is selected in the build properties) or set a version for the build. Only when you press the Build button in the build specification properties does the version get incremented automatically, not via programmatically.

Answer 1

In versions before LabVIEW 2014, this was truly difficult, as the Version Number for a particular Build Spec is stored deep within the XML that is part of a Project (modify at your own risk).  There are also some inconsistencies in the XML Tags, in particular whether the third dotted number of the Build Spec is called "Fix" or "Patch".
LabVIEW 2014 introduced a Set Build Specification Version that allows you to set the Build Spec within the Project by supplying the name of the Target (usually "My Computer"), the name of the Build Spec, and the path to the Project file.  There is also in LabVIEW 2012 and higher (I don't know if this is present in LabVIEW 2011) a Build option called a Pre-Build Action, whereby you can specify a VI to run before the Build takes place.
In my LabVIEW implementation, my LabVIEW Projects live inside folders that are part of a SubVersion repository.  I wrote a utility that, given the path to the Project File, can return the SubVersion Build number.  Using the Pre-Build Action, I can call this Utility, get the SVN Build Number, and use Set Build Specification Version (or other LabVIEW code to diddle the Project XML file directly).
This, in fact, works, but there's a bug -- the file that results from this Build does not have the Build number specified by the Pre-Build Action.  It turns out that as part of the Build process, the Version is cached first, then the Pre-Build Action is applied (updating the Version, perhaps), then the Build takes place using the cached Version.  The "simple fix" is to Build twice -- the first time to save the SVN Version into the Build Version number, the second time to use this saved Version number in accomplishing the Build.
I've alerted NI to this conundrum.  I didn't get the sense that they are willing or eager to change this behavior.
Bob Schor