How to Automatically Show your SVN Revision in your LabVIEW EXE
By Henrik Hjorth
A common way to get a new version number when building an application is to use the “auto-increment version on build” feature that is available in a LabVIEW build specification. This way you’ll get a different version than the previous build but has the disadvantage that there is no direct link between the build version number and the version control system (assuming that a source control system is used).
Another approach is to include a revision number from the source control, and if using SVN, for example, this process can be automated into the build process. By using the SVN revision number, it’ll get easier to trace the actual source of a certain build.
The first step is to ensure all files built into the application are in version control; obviously, a file that is not known in the source control will never get assigned a revision by that system.
The second step is to enable the pre-build action. Open the build specification in the project, select the Pre/Post Build Action tab, and enable Execute VI before build. Generating a VI will create an empty VI with a defined set of inputs.
In the pre-build action, we’ll add some code to get the SVN revision number for the project being built and then update the build version in the build specification with that number. There are probably several ways to get the SVN revision number, but here are a couple of ways that work: Command client tool
If the svn command client tool was installed with the Tortoise client (this option is by default disabled in the installer), the System Exec VI can be used to get the revision with the following command:
svn info -r HEAD –show-item=last-changed-revision
The output will be the revision number, no parsing is required.
SubWCRev tool
If the command line tool is not installed, a utility called SubWCRev can be used instead (this only works on Windows). This can be done either by calling the SubWCRev.exe or by using the ActiveX object that comes with this tool; here the ActiveX variant is shown.
Add an automation refnum, right-click and select “Select ActiveX Class”, then browse and select SubWCRev Type Library that should be found in the list.
Then add the following nodes to the block diagram and connect them as shown here:
There are also other properties that can be read from the property node, such as if an item is not in revision control or has modifications. The next step is to add the revision number to the version information in the build specification. This is easily done by using the Get/Set Build Specification Version VIs that are found in the Application Builder palette.
The last step is to build the application. Unfortunately, NI didn’t design the pre-build action feature for the use case of modifying the version at build time (and has no plans to do so either). The current build, therefore, needs to be aborted and a new one started, either manually or programmatically. The downside to starting a new build programmatically is that the build progress status window will not show any feedback in this case, so a manual restart is the preferred choice here. Aborting a build is easy, just set an error out from the pre-build action VI. A custom error message can be added to inform the user that the build version was updated and to restart the build. Next time the build process is started, the version information will be correct and the build application process will start as normal.
If combining the steps described above, we’ll get this pre-build action VI
The result when starting a build is that the first time it gets aborted and the Build Errors dialog is opened. When restarted, the build progress window is opened and the application gets built.
Of course, there are also ways to create your own application builder, including progress updates and error information, by using the Application Builder API, but with the approach above the revision number will be shown in your built application without too much investment of time and effort.