LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Saving Version/Build # for Quality Assurance in EXEs

This was a problem I had no luck in finding answers to in the forum and just wanted to pass along what I discovered for others to use.

The challenge I was having was to try and save a version/build # into an executable that would allow the user to uniquely determine what version of code they were running, without using external ini, configuration, or registry options--I wanted it built into the executable itself, and I wanted the build # to increment every time I ran my code in the development environment since this would be a pretty good indicator of when the program was compiled in relation to the same program compiled at previous or future points in time.

The solution that finally worked for me was to create a version tracker VI with nothing but a version integer and build integer. Every time my program runs, I open this VI using a reference and read what the version and build are. If the program recognizes that it is not compiled (no ".EXE" in the file path), it adds one to the build number, writes the new value to the VI and saves it. Good example code for saving the default values of the front panel is available elsewhere in the forum or here: http://www.originalcode.com/SavDef.htm

In order to save the front panel however, the VI cannot be running, which means no linking to it. Which is fine, until you compile, and since there is no link to the file, it is not added to the executable. The solution to this is to add the version tracker file to the source files list as a dynamic VI... this will save it into the executable without setting it's front panel to load on open as a top-level VI would.

The final behavior of this process was exactly what I was looking for. Every time I run the program in development mode, the build number increments and is displayed on program startup. After the program is compiled the build number is 'locked in' and displays on program startup. It is locked into the executable and cannot be changed, erased, or accidently overwritten. It is also possible to use anything for the build #, including the last time and date that the program was run in the development mode, etc.
0 Kudos
Message 1 of 3
(2,599 Views)
You are doing what we do for years. We maintain a global variable containing the the version and release date. The only thing is we do this manually. Our release number will be incremented only when I deliver the exe to my customer and not for each run of any test. Also the release date will not be the actual date the program is builded. Sometimes my custumers want a explicit release number and date. E.g. the build will be short before christmas but the release date ist Jan. 1.
Waldemar
Waldemar

Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions
0 Kudos
Message 2 of 3
(2,599 Views)
for you and many others i'm sure that's fine--anyone can stick a constant in their program and update it manually. it doesn't even need to be a global variable. what you're forgetting though is the laziness factor 🙂 i do no manual updating and can tell the difference between any compiled version of my program.
0 Kudos
Message 3 of 3
(2,599 Views)