Get LabVIEW Executable Version Programmatically

[G-Money]

Overview

This VI returns the File Version of the Executable calling this function

Description

This simple example code is very useful for built applications. If you have ever wondered what executable version you are using and don't want to find it in the local properties of the executable (remember that this property needs to be turned on in the Build Specifications for this to work), then this will help you out. Using the Current VI's path and Invoke Nodes, I parse out the version information and view it on the Front Panel.This VI uses the .NET Assembly to get the executable file version.
1. Create a .NET Class Reference constant and link it to the System Assembly then browse to System Diagnostics and choose FileVersionInfo
2. Use the FileVersionInfo Invoke node to get the version info reference of the executable file name
3. Use the FileVersionInfo property node to read the File version

Requirements:

LabVIEW 2012 (or compatible)

.NET Framework 3.5 (or Compatible)

Steps to Implement or Execute Code
1. Downlaod the attached folder "Get Executable Version Infomation_LV2012_NI Verified"
2. Navigate to Build Directory

3. Launch the Executable Test.exe and view its version  displayed

4. Open the Project "Executable Version Information_LV2012_NI Verified" and then the "Get Executable Version Information_LV2012_NI Verified" VI to view the code

Additional Notes or References

Block Diagram of the "Get Executable Version Information_LV2012_NI Verified" VI

Executable Interface

*This document has been updated to meet the current required format for the NI Code Exchange**

[Thoric]

Does this use .NET ? If so, it will work well under Windows, but not Linux or Mac.

[ErikL68]

It sure would be nice if this were a VI Snippet or at least included a download.  I can't seem to locate the "FileVersionInfo" class for Invoke Node.  I'm running  2009 f3 & 8.6.1 and neither version has it.

[mrey]

I couldn't find "FileVersionInfo" either, but there is another example that had the code:

http://decibel.ni.com/content/docs/DOC-1293

[ErikL68]

mrey - thanks!

As it turns out, I requested support and was forwarded to this article:

http://digital.ni.com/public.nsf/allkb/935BA7FB426305398625711E0055F1FA?OpenDocument

It refers you to FileVersionInfo.vi, found in VI.lib\Platform\fileVersionInfo.llb that they recommend you use over this method.  It worked fairly well, pulling all sorts of data that Windows Explorer would give you (File Version, Product Name, Internal Name, Company Name, Legal Copyright, and File Description) for pretty much every EXE and DLL I tried it on, though curiously it failed with an error trying it on a self-extracting WinZIP file (an NI patch for LV 2009).   Curiously, I tried it with the Dlb_About.vi you link to and while it didn't return a version, it at least didn't return an error (though that could be handled obviously).

Like in the example you sent, you must wrap the VI in a case statement so that it only executes when the App.Kind = "Run Time System" or you'll get an error.

[kitsik]

Thanks a lot. Very usefull !!!

I was looking inside Labview, nothing regarding build version to fetch ...

[kitsik]

Finally i implemented it, thanks to all for information:

How can i attach 'File_Version.VI' here ?

[kitsik]

For a while, the first case:

---------------------------------------------------------------------------------------------------------------------------

The second case:

[Tookys]

There is an issue with the code as is.

If you use this code in a SUB-VI, it has to be in the same folder or a parent folder of the ROOT VI for your executable. I had spent the better part of an afternoon trying to get this code to work. And i was confused because it would work fine in the example project when compiled, but wouldn't work in mine. This is because I was moving it to a sub folder, and when it runs it directs a path to the subVI inside the executable, and not the executable itself.

To resolve this issue you can trim the path string to stop at the executable. Doing this allows the SUB-VI to be anywhere at compile time.

I would recommend anybody trying to get this to work, to look at Mercuri 's example code in the following discussion -> http://forums.ni.com/t5/LabVIEW/How-do-I-get-the-application-build-version-into-my-VI/td-p/873434

The path editing solution i mentioned above, I found by looking at his code, his code also handles the issue of running during development very well, giving the same version number during development as it will as the next executable.

His sample code, I will be keeping in my list of VI's to hold onto for future projects.