What's the best practice for two installers? "full & upgrade", "app & dependencies", other?

[Jim Kring]

I'm curious about the best practices and caveats others have discovered related to using LabVIEW's built-in installer builder for distributing apps efficiently.

Note: I saw an old post by crelf here where there was some discussion of approach #1, below, and a follow up by Tonn Plomp about that mentioned the problem I've sited below.

Problem

Application installers that include dependencies (e.g. LabVIEW Run-Time Engine, IMAQdx, DAQmx, VISA, etc.) can be quite large. When users are upgrading to new versions of your application, it would be nice if they could just download the new application, and not have to download the dependencies, if they have not changed.

Solution (over-simplified)

Separate the installation of the application from the dependencies, and manage this all somehow.

More details on approaches...

= Approach #1 / Have two installers: "Full" (App + Dependencies) & "Upgrade" (App only)  =

How: Copy the installer rules and delete the dependencies. Call this the "Lite" or "Upgrade" installer.

Problem: The full installer and lite installer will likely have different product guids (component codes / installer IDs), so Windows will treat them as two different applications. And, since they are installing your application into the same location, there will be a conflict. The installer will not actually uninstall the old files first (maybe, or other bad things will happen that we can't predict).

= Approach #2 / Have two installers: "Application" & "Dependencies" =

How: Create an installer that includes the application and the dependencies. Then, make a copy of this and remove the app, so that only dependencies are installed -- call this "Dependencies". In the original installer build spec remove the dependencies -- call this "Application"

Problem 1: The first time the software is installed, the user has to install two separate things: Dependencies and then Application.

• Solution: In the "Dependencies" installer, include the installer for Application as additional support files, as well as a batch file that gets called as a post build spec to install the Application, after the Dependencies get installed.
  • Bonus: call this installer "Full Install" since it now includes the Dependencies AND the Application -- but, note that it's structurally different than the Full version in Approach #1, above.

Problem 2: What happens when the dependencies for your application change? (e.g. if it requires a new version of the run-time engine or if you start using some other LabVIEW feature that requires an additional support installer)

• Solution: Use some kind of versioning scheme where users understand that major releases of the Application will require upgrading the "Dependencies" installer to the same major version, too.  

= Approach #3 / Use a package manager with dynamic download and dependency management capabilities =

OK, we know this is the best solution, but let's explore what folks are doing with the above two approaches, for now...

 

Looking forward to hearing what people are doing and what your thoughts are on these approaches I've outlined.

[drjdpowell]

I’ve been doing Approach #1.  I haven’t encountered the problem you mentioned, though.

[hooovahh]

Yeah I'm an Approach #1 guy.  Starting in 2010 I think the application builder settings allow you to change the GUID, before that you could edit the .lvproj file in a text editor.  So I just copy the GUID from one to the other, so Windows believes the program is an upgrade.  So if I install 1.0.0 full (with all RTE and dependencies) and then install 1.1.0 upgrade (just app) Windows knows to remove the old app and replace it with the new, and in add remove programs it only shows the 1.1.0 version installed.

I'm not sure I'm a fan of the "Full" and "Upgrade" naming but it is what I've been doing for years.  So I will have a "Test Application 1.0.0 Full", then "Test Application 1.1.0 Upgrade"  There could of course be a 1.1.0 Full (with all dependencies) but it seems unnecessary to release a full with every version.  But the reason I don't like the naming of Full and Upgrade, is because to me that implies an upgrade can only be installed after a full.  And for me there are some applications that only require the RTE and that will likely be on the test machines already.  So in this case I'll know I just need to install the Upgrade, but other engineers may not know that and will take the time to install the full, then upgrade.

Another issue I've seen is when engineers don't know the steps to get the latest on a fresh machine because of multiple Full installers.  Lets say I made a 1.0.0 Full, then 1.1.0 Upgrade, then a 2.0.0 Full, then a 2.1.0 Upgrade.  It isn't clear what should be installed to get to 2.1.0. Do I need to install 1.0.0 Full, then 2.0.0 Full, then 2.1.0 Upgrade?  I can't think of a good name that is short and basically means with dependencies.  Of course knowing what those dependencies are and if you have them is another issue so I probably just won't change anything for now.

Other than these minor issues I'm pretty happy with the solution.  The other approaches you mention sound fine but this seems pretty easy to manage, and works by just using the NI tools (like no inno setup to manage).

[Cat]

I used to do Approach 2, then a user moved an exe to a different computer -- that of course didn't have the dependencies installed for that exe.

Now I do Approach 1 which works best if you don't always jump on every LV yearly upgrade and SP. I tend to upgrade every other year, so can go for a long time without needing the "Full" installer.

Approach 3 is fine -- unless of course you aren't tied to a network, or don't have the concept of a "server" in your network...