Many similar installers or universal installer?

[Gregory]

Hi there,

I'm just curious what people do when distributing executables. By creating an installer with LabVIEW and letting it select required components, it is easy to make sure I have all the runtime components I need to use an application. But, it also means each application installer can take up 100s of MB on the server. Maybe this isn't an issue with how cheap hard drive space is, but it seems like a waste to have duplicates of the LabVIEW runtime engine installer everywhere.

Does anyone use a more general installer including the LabVIEW runtime as well as extra components like NI-VISA, IMAQ, etc. that you can use for all of your applications, even if all these components aren't used by every application? 

Just looking for what other people have had success with when managing test software distribution on in-house test stations. 

[Hooovahh]

I've made a few posts on this over the years but for some reason can only find this half attempt at answering this question on LAVA.

https://lavag.org/topic/18959-automatic-upgradedowngrade-from-installer/?do=findComment&comment=1140...

Basically what I suggest is making two installers in the project, each with the same Upgrade Code so Windows thinks it is the same application.  I then make a Full installer with all run time engines and everything.  And then every other installer is the Upgrade with just the built EXE.  I could then have a Full 1.0.0, and Upgrade 2.0.1.  If the computer had ever installed a Full (meaning all run time stuff is there) then you just run the latest upgrade.  If this is a new computer with no NI stuff at all run the Full, then the newest upgrade.

[Kevin_Price]

Good question.  I tend to put together multiple build specs for released code and name the subfolders accordingly to identify them:

- EXE: to build the basic app and occasionally some tightly-coupled INI or other support files.  The EXE is needed for installers, and many times upgrades can be done by copy-pasting this build folder.

- APP: an installer to put the application and support files where I want them to end up on the target.  No drivers are included in this one.  The intent is that the APP installer will upgrade a machine with a prior installation.

- FULL: the whole shebang, with all needed drivers, MAX config, etc.  This is normally only needed for a first install on a fresh PC.

- SOURCE: the source distribution brings together project source code with a snapshot of common reuse code used from user.lib and similar places.  We have some internal packages that are in active development.  2 years from now, my original development directory of source code might be broken due to changes in these packages (yeah, yeah, I know.  We *try* for backward compatibility, sometimes it's hard).  The source distribution makes an archive of all the source code as it existed at the time of the EXE build.

I had an idea to try to make a "platform" installer that would have no LabVIEW executable at all, but just install the commonly used drivers like DAQmx, VISA, Serial, MAX configuration, etc.    I wanted a single generic FULL installer for all the platform stuff that I could keep reusing for all the individual apps.  Then the individual apps would only need the much smaller EXE, APP, and SOURCE builds.

   Unfortunately, I didn't find a way to do it.  Granted, I didn't try real hard b/c hard drive space is cheaper than time.  Thinking about it again now, I could probably make a no-op EXE that would let me make a platform installer with all the drivers, and then have it do a post-build uninstall of just the application.

   What's the better way that I don't know?

-Kevin P

[Gregory]

@ Hooovahh

The full installer does take a while for LabVIEW to generate, so I like the idea of just creating it once, and then creating the update installer from then on.

@ Kevin_Price

The platform installer is what I was trying to describe with the universal installer and I was planning to do it exactly as you described but did not consider an uninstall step. 

I have been thinking of a good way to handle re-use code. For now I have been making copies for each new project, so I already have a "snap shot" when the project is saved to source code control, but it will stink when I find a big error in my re-use code that I need to correct across many projects...

[Hooovahh]

---

@Gregory wrote:

The full installer does take a while for LabVIEW to generate, so I like the idea of just creating it once, and then creating the update installer from then on.

---

Yup that's what I was describing.  In your project you have two installers, a Full and an Upgrade.  You make a Full 1.0.0 which is big and takes a while.  Place it on the network and install it on the PC that has no other NI stuff installed.  Then build Upgrade 1.0.1 using the same upgrade code (Windows will think this is an upgrade to an already installed product).  This will include just the EXE no runtime engine.  Place this on the network and install this on the PCs you want.  Then keep making Upgrades as needed.  Upgrade 1.0.2, 1.0.3, 1.2.0, etc.  Then when you have a new PC with no NI stuff installed, go back and run the Full 1.0.0, and when it is done install the Upgrade 1.2.0 which just updates the EXE leaving all the run time stuff that the Full 1.0.0 installed.  You can optionally make a Full 1.2.0 and you'll just need to install that but obviously it will be big you may just want an updated EXE.

---

 I have been thinking of a good way to handle re-use code. For now I have been making copies for each new project, so I already have a "snap shot" when the project is saved to source code control, but it will stink when I find a big error in my re-use code that I need to correct across many projects...

---

VIPM and packages.  For any project you can create a VIPC which is a configuration of all packages required by the project, including the versions of each package.  Now when you want to roll back to that snapshot, revert your SCC and apply that VIPC (which can be saved in SCC).  This requires the pro version so most people don't do this but you can also just keep track of what packages were installed for what projects manually.