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.

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

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.