Issuing a "Patch" with LabVIEW-Built Installer

[John_P1]

Is there a way to make a "patch" using a LabVIEW-built installer?  For example:

1.  Installer A (call it version 1.0) creates some files on disk.

2.  Installer B (call it version 1.1) overwrites a subset of the existing files (it also adds new files of its own).

From what I can tell, if installer B and A share an upgrade code, running installer B will first run uninstaller A (deleting everything created by installer A, I have some state in these files I want to preserve).  If I could run an executable before running the uninstaller I could perhaps work around the issue by caching what I need to, but alas this project uses LV 2011 for the time-being so that's not an option (the option to run an executable before uninstallation was added in 2012).  Also, installer A is already released so I can't go back and add this feature anyway.

If installer B is given a unique upgrade code it will overwrite the files it needs to (assuming the user points the installer to the same directory), but now Windows thinks there are two different programs installed with the same name.  I could track down the registry keys associated with installer A's GUID and delete them using a post-installer executable, which should take care of this issue.  I think this would work but it's a bit messy, and I don't like relying on the end-user to point the installer to the correct directory.

Windows Installer allows for creating a patch (.msp), but as far as I can tell LabVIEW cannot make use of this functionality.  I'm thinking my best bet might be to use something else for building the installer.  

Does anybody have any thoughts or suggestions about this?

Best Regards,

[Jeff-P]

Hi John,

I looked into this and from what I can find it is not possible to make a patch installer easily in LabVIEW. For most users this is fine because they have small installations, but I understand your concern with maintaining state. You could try doing something similar to what LabVIEW itself does - generate an .ini file on first launch to store configuration data. Since the file is dynamically generated as opposed to an installed file, it will not be removed by the uninstall process. This has the advantage of allowing you to maintain configuration data when doing an uninstall/reinstall, but has the disadvantage that you leave files behind after an uninstall. As you noted, LabVIEW 2012 gives you the option to run an executable before uninstallation, and it might be possible to add logic there to clean up those dynamically generated files during a full uninstall vs a patch install. Unfortunately that isn't an option for you since you are staying in 2011. You also have the option of going outside the LabVIEW installer builder and building your own installer, which would let you leverage the windows patch installer functionality you described.

Overall this sounds like a great candidate for the idea exchange, I would be interested to hear how many people are trying to do this.

Hope that helps a bit, maybe somebody else can chime in who has done something like this before

Thanks,

Jeff Peacock 

Product Support Engineer | LabVIEW R&D | National Instruments 

[John_P1]

Thanks for the feedback--I'll have to collect my thoughts a bit before posting to the idea exchange so I can be more specific about what exactly it is I would be asking for and how it would look in the context of the LabVIEW project (although if somebody else wants to take a stab at it, by all means go for it).

Best Regards,

[Jed394]

I've run into this same issue before and couldn't find a good solution either.  I just manually overrode things with copy and paste.  You might try posting in the Lavag.org forums.  Those guys might have some good advice.  

[John_P1]

I found out that the components created by the LabVIEW installer each have their own key in the registry under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\...\Components.  Each key has one value in it corresponding to the path/registry location for the component created by the installer.  The value is named some string of characters that is unique (but shared by all the components created by my installer).  With this in mind, I tried the following:

1.  Made a new upgrade code for my more recent installer.

2.  Install on top of the old installation (does not uninstall old version yet due to the new upgrade code).

3.  Post-installer executable handles the rest by:

a)  Find GUID of old installation by searching HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall for my program name and version.

b)  Using the GUID, I search through the components in the registry to find the unique value that is shared by all components created by my installer.

c)  Using the unique component value, I find all component keys for my product, and delete the ones that I want to remain installed on the system.

d)  Run the uninstaller (obtained from the uninstall registry key mentioned in step a).

I'm sure Microsoft wouldn't approve, but it seems to get the job done.  The uninstaller for the old version does run and removes all components except the ones I specifically want to remain on the system (config files, log files, license key).  I'm still validating though.

As suggested, newer versions of my application dynamically create these components (not as part of the installer) so I don't have to worry about this moving forward.  However, I needed something like this to handle the upgrade from an already deployed version.  

Manually copying files wasn't really an option since the software is deployed around the world.

Best Regards,

[John_P1]

What I would have liked to do instead would have installer B looking something like this:

1.  Run pre-installation executable that checks for presence of installation A.  If it is present, installs a patch which modifies uninstaller A to not remove the files I need.

2.  Run the normal installer B (which would first run the patched uninstaller A, then installer B).

However, I can't build a patch in LabVIEW as mentioned before, but even if I could I can't run a pre-installation executable anyway.  The ability to run a pre-uninstallation exe doesn't help me for software that is already released.

Best Regards,

[Wart]

I've switched to using Inno Setup to handle installs largely for this reason.  I have the initial setup call a normal NI installer that has everything bundled in it.  All of my updates are done without NI installers and only with Inno.  I have two seperate Inno scripts, one for an initial install, and one for handling upgrades.

Inno can read from the registry and you can base actions on if a key exists or not.  This lets me do things like only installing dependencies if they don't already exist.

It was a bit of a learning curve to come up to speed on Inno, but it has made keeping a fleet of computers around the world updated possible.