Saving Version/Build # for Quality Assurance in EXEs 
Author Message
 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.*-*-*.com/

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.



Sun, 21 Aug 2005 07:33:37 GMT  
 Saving Version/Build # for Quality Assurance in EXEs
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


Mon, 22 Aug 2005 00:24:48 GMT  
 Saving Version/Build # for Quality Assurance in EXEs
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.


Mon, 22 Aug 2005 01:29:27 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Question about forum for comments on quality assurance

2. "Quality Assurance"

3. Quality Assurance and Testing guidelines

4. SANFRANCISCO - QUALITY ASSURANCE ORIFESSIONALS

5. ANNOUNCE: quality assurance: another python lint (and python parsing in python)

6. Product Update CWRES 2.0 - Add version information to Clarion EXEs

7. Add version information to your Clarion EXEs

8. SCM version 3c13 MS-DOS EXEs ?

9. Save an entire project at once, made in version 6.1 to version 6.0

10. Ada 95 Quality and Style Guide - PDF version

11. SPC Ada Quality and Style guide, version 2

12. How can I save a VI into llb programmatically and build application

 

 
Powered by phpBB® Forum Software