Automatically updated version/build numbers: Exposing them programmatically for Help/About...menu item or Panel title

[sth]

This idea was posted years ago and declined for lack of interest  (it got 6 out of 7 necessary, but I would have been the 7th!).  I would like to bring it back, I would like my application to have access to it's own version number.  In fact you can open the project programatically and see some build properties but not that one.  I can then grab the version from the build properties and set the default values on my FPGA code before compiling.

I was trying to make a pre-build VI that would look at the build properties and copy the version data into a control.  Can't be done.  I find this very useful to make sure that my RT system and my FPGA code have the correct versions.

Same as with an about box, or version checking for compatibility.

The previous thread suggested a routine in the FileVersion.llb but that seems to only be available in a single platform.  Not useful for RT linux or Mac.  The version is not available until the executable is built which does not work for FPGA.

At the moment my only recourse is to hand copy the version from the build properties and then set those as a series of 4 integers on the FP.  (Then select them all and set their values to default, hence the other suggestion about right click)

[wiebe@CARYA]

Getting\Setting the version(s) isn't hard, I I've been doing this for years...

'Simply' get the build spec's tagset, and change the Bld_version.build tag.

I have 4 executables and 4 installers in my build spec. Opening the installers takes about 4 minutes each (sigh). So I had to made a VI to change the versions of all the executables and installers. Takes a fraction of a second...

Similar for Bld_version.minor, Bld_version.major, Bld_version.patch...

Reading it is indeed OS specific. AFAIK, the exe file itself doesn't contain the version number. It's stored in the file properties of the file system. Indeed, on Windows.

Haven't tried this for FPGA.

As you can read the version, you can store it in a Conditional Disable Symbol in a prebuild action. This has the negative effect of changing the project. You can read the symbol in the exe... Or you can store it in free label or default control value with scripting.

If the idea is to make this mess easier, then +1... 

[sth]

Well that could work for me.  What is that obscure GUID in the Project Item type?  This gets the Build version for the first project descendent?

BTW: the version is stored in a file in the application bundle on the Mac OS.  This is available using shell or applescripts.  And I use it to display the version number of the built application on the Mac.  But this could retrieve it and set a FP variable in a cross platform manner?

[wiebe@CARYA]

>What is that obscure GUID in the Project Item type? 

It is indeed an obscure GUID... One that matches an exe build specification.

I'm not sure where I got them, but if you travers a project with other build specs,  finding their GUIDs should be easy.

[sth]

Maybe it should be a bit easier?  It turns out that Major/Minor/Build are stored in the project file as properties but "fix" is not!!!???  Getting the Tag Bld_version.patch or Bld_version.fix fails.  I do have a "fix" version set, but if it isn't in the project file.

In fact if the patch value is zero, the returned variant is empty but not a zero value.  This is just a lot of code to work around weird NI "unexpected features".  Why is this not just a property that has a value or are all properties going to be moved to tags now.

Off to go detect an empty variant and then substitute 0.

[sth]

And it does not work on FPGA build Specs for some reason....  Type {F4C5E96F-7410-48A5-BB87-3559BC9B167F} fails.  Aha, poking into the lvproj file, FPGA builds have "Comp.Version.Build", "Comp.Version.Fix", "Comp.Version.Major", and "Comp.Version.Minor".  Of course consistency is the foolish hobgoblin .....  etc. etc.

Yes, this could be made a lot better.

[KiwiWires]

C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\Platform\fileVersionInfo.llb\FileVersionInfo.vi

This works OK for a built application in Windows. Gives Project file info in development and EXE info in the EXE. I haven't tired it for anything else. Looks like it calls windows DLLs.

[wiebe@CARYA]

Getting the version on Windows wasn't the problem:

---

@sth wrote:

The previous thread suggested a routine in the FileVersion.llb but that seems to only be available in a single platform.  Not useful for RT linux or Mac.  The version is not available until the executable is built which does not work for FPGA.

---

The only hack I can think of is reading the version (hard and inconsistent) and store it with more (hard) scripting magic.

Yes, things could be improved.

[sth]

I think I can read the version now for each build spec, both regular, RT and FPGA with appropriate cases.  I don't normally see the TagSet property since I didn't have scripting turned on in this particular VM.  Now for each build spec I have to get the top level VI (or Source[1].ItemID??) and then I can make that version available to the actual program/executable so that version checking can be used in a cross platform manner.

Why is not the version just a readable property of the build?

[wiebe@CARYA]

I think it is, but it has a default. If you didn't change it, it's not stored and the default is used.

Just to make things more complex.

[rolfk]

Making the <vi.lib>/Platform/fileVersionInfo.llb/FileVersionInfo.vi support to read the application bundle on the Mac wouldn't be that difficult. What I have failed to find is a consistent way of storing application version information under Linux. AFIK it doesn't exist!