Massive update of LV versions

[CoastalMaineBird]

I have been working on a large project for 10 years now.

The main program is called "HDT" which does data acquisition (so it must have DAQ hardware), and there is a subprogram "DFV" which is a data file viewer/analysis program, which can run on an engineer's desktop (with no DAQ hardware).  Each DAQ installation includes a PXI (real-time) box, attached to a host (Windows) computer.

We stayed with LV 2010 for a while, and upgraded to LV2013 last year.  We are now doing a large re-vamp of the whole thing.

I mentioned to my client yesterday that LV 2014 was coming out soon, and that it might (MIGHT) include some new UI widgets that would simplify a UI issue we are working on.

Here is is response, verbatim:

{...} but there are still a lot of tasks that come up when we do such upgrades. 

There are 26 installations of HDT as DAQ and over fifty other installations of the standalone DFV. For each HDT and DFV installation (>76), I would need to run an installer to update the runtime engine. For each HDT DAQ install, I would also need to reinstall the runtime engine on the RTOS. For all of these installs, there is a LOT of scheduling involved and a fair amount of labor. 

IOW, we need to have very good/strong justification for upgrading LV versions. 

The "scheduling" he refers to is finding time in between tests (which use the equipment) to bring it down and do the upgrades.

QUESTION:  What can I do to reduce the pain and suffering of a mass migration from one version of LV to another?

[Hooovahh]

Make a single installer for all dependencies for an application.  This single installer should contain your built EXE, the run-time engine needed, the DAQmx tools, the MAX configuration, the application config, and all other needed tools.  This way you have one installer to run, that just does it all.  This one installer can have the same "upgrade code" for Windows so when you install a 2014 build Windows believes it is an upgrade for an existing application.  Replacing shortcuts to the new version and removing the old version.  If you want the old version back, go and get that single installer built previously and install it.

Most installers can have a silent install command.  The NI ones do.  If you are deploying to many systems, you can have a startup program that looks on the network for a new installer.  Then installs it using the silent switch automatically.  So after all your testing and making sure that single installer works fine, just place it in a directory on the network, and when you come in the next day all testers will be updated and ready to run tests.

ISTool builds Inno Setup files that I have used in the past to make a single installer, when the NI one just can't do what I needed.

[Henrik_Volkers]

Call it a Windows security update 😄