How to determine which RTE a built application needs

[herbert.niesler@emsolutions.com.au]

  Hi,

         I am at the stage where I have a number of built applications that are used around my company.  They are built in LV2010, 2012 and about to be 2013.  It is now getting to the stage where I might have to install up to 3 RTE's on any PC that wants to use the built applications.  Alternatively I could try rebuilding all the apps with 2013, which I want to avoid.

  To help manage this situation, is there any way of determing which RTE a particular built application requires?  It would help identify which RTE I may need to install or which built applications I really do need to rebuild.

     Cheers

              Herbert

[altenbach]

You can try to run it without the run time engine installed, and it will tell you which version it needs.

If it is already running on another computer, you can look at "help...about" to see the version it is running under (assuming you did not customize that menu entry away).

Not sure if there are other ways.

[Sam_Sharp · Accepted solution]

I think this might work for most cases...open your executable with a text editor like notepad (or notepad++ etc.). Search the file for "LVRT" and you should see the version number nearby somewhere.

See the example below from a LV2012 executable:

I've checked it with a LabVIEW 2010 and LabVIEW 2011 executable so it'll work for the last few versions of LabVIEW - I suspect it'll probably work for most versions.

[herbert.niesler@emsolutions.com.au]

Hi Sam and Altenbach.

                           Thanks very much for your suggestions.  They give me a range of options.  Looking into the built app file is very useful as I can automate that process, can confirm it works for LV 2012.  The other suggestions are useful for when there is human intervention.

          Cheers

                 Herbert

[rolfk]

The way I handle this is by several means. One is the project management itself which contains a label in the main folder that specifies the LabVIEW version it is last compiled in. This also helps to make sure you don't inadvertently open a project in a newer version and end up with a recompiled version that may get written back to disk accidentially (although that shouldn't be a big problem as you are using a version control system, don't you?)

The other method I use is that in my own About dialog that each application has, there are text strings that show both the version number of the application as well as the version number of the LabVIEW system. The application version number (together with a version history) is stored in a central VI inside the project that gets updated whenever I make modifications to a project. The LabVIEW version is read through a property node (Application.Version Number) and displayed in the dialog.

[herbert.niesler@emsolutions.com.au]

  Hi Rolf.

           Thanks for your thoughts, it is interesting seeing different solutions to this issue.  I can see your system works for you.  In my case I have a number of different ways the test programs are launched.  They all rely on the path not changing, so having a version number in the filepath would not work for me.

   As I don't have the infra-structure that you have in place, it is easier for me to be able to read back what is actually in place.  I have implemented the automated reading of the built application for its desired RTE version (as suggested by Sam) and it works nicely.

        Cheers

                  Herbert

[rolfk]

I understand that that would work too. It's just a rather brittle way IMO, that is prone to fail at some point due to changes in the way NI might handle the linking to the RTE in future versions. Also it is a Windows only solution which in my case is not always appropriate.