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.
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.
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.