Programmatically deduce the LabVIEW Version

[Bob_Schor]

I had written a routine that I used to "reset" the Channel Wire repository (as a Channel Wire "User and Abuser", I tend to find interesting "edge cases" that fail to compile unless you "start from Scratch" with no Channel Instances already defined).  To do this, I need to know what Version of LabVIEW is being used for Development.

I went looking, and didn't find one, so I started "playing" and invented (or, probably, "re-discovered") two methods.

One uses the LabVIEW Project file (I use LabVIEW Project for my "LabVIEW Projects", so I'm working with a "known structure").  Assuming the VI is in the Project Folder, I find the Folder by looking for a file with the extension, which should be in the folder holding this VI or a higher-level folder.  I open the Project file and isolate the second line, which contains a string of the form <Project Type="Project" LVVersion="19008000"> (the Angle Brackets, < >, are the beginning and end of the String).  I isolate "19" and add 2000 to it to get the LabVIEW Version.

The other way is to look at the VI itself, which (of course) is largely in binary.  At an Offset of 227 bytes, there appears to be a 12-byte location where the characters "19.0.1" and six trailing NULs (byte value 0) occurs -- isolate the "19" (I'm using LabVIEW 2019) and add 2000.

Both these methods seem to work, but they strike me as something of a kludge.  Is there a better way?  [If it is a secret, and you trust me not to blab it around, you can send me a Private Message ...].

Bob Schor

[mcduff]

Would this work?

[billko]

The project file read - <sarcasm>you mean you didn't use the sloooow native LV xml parser?</sarcasm> - has good points and bad points.  The good point is that it's easy to read.  The bad point is that it really only guarantees that the project file is a that particular LV version.

The VI binary read has good and bad points as well.  The good point is that it guarantees that that particular VI is at that LV version.  The bad point is if the format changes, you're screwed.  Hey, it could happen.  NXG wanted to become LV Classic successor.  (But it would've become much easier, since the GVI is just a big xml file.)

edit:

I totally missed the point of Bob's post.

[rolfk · Accepted solution]

What is wrong with the VI Server methods?

The App properties retrieve the LabVIEW version.

The App method specifically works without loading the VI into memory so doesn't mess with a loaded VI hierarchy. The binary offset method definitely is not reliable. The VI resource file format is highly dynamic and you were simply lucky that it seemed to be always at that specific offset.

[Bob_Schor]

My thanks to McDuff and rolfk.  I (of course) knew my methods were a kludge, and was hoping for "better advice".  I haven't used VI Server for many years, so when I was searching, I overlooked these (and several other) possibilities.

I found it interesting that the Version Number returned by the Get VI Version method (Invoke Node) returns a U32 that, when interpreted as a Hexadecimal quantity, is 19008000, the same "human-readable" characters that appear in the second XML line of the LabVIEW Project File.

And to answer billko's question/suggestion, I didn't even try to use LabVIEW's XML parser to extract the Version number.  I've played a bit with XML (I "successfully", which means "I'm pretty happy with the results I got", used the GXML Package from the LabVIEW Tools Network, and even "extended and improved it" a bit, and have also tried EasyXML from JKI), but found the native LabVIEW implementation "confusing".

Thanks to all for the help.

Bob Schor

[rolfk]

---

@Bob_Schor wrote:

I found it interesting that the Version Number returned by the Get VI Version method (Invoke Node) returns a U32 that, when interpreted as a Hexadecimal quantity, is 19008000, the same "human-readable" characters that appear in the second XML line of the LabVIEW Project File.

---

That is simply the internal LabVIEW version number. It's format in hexadecimal view is as follows:

MMmFSBBB

MM: Major version number, so we can go up to 99 before it gets complicated

m: minor version number, 0 - 9, theoretically also A - F but that would be confusing

F: Bugfix version number, this is actually the SP number nowadays, the f4 bug fix releases are not contained in this version number

S: Stage, Development = 2, Alpha - 4, Beta = 6, Release = 8

B: Build number

Since 2009 the last two digits of the year result in the Major version number.