Installshield : custom action to uninstall previous version and install the latest version

Question

My requirements are as follows:

1. If an application with version e.g. 12.0 is installed at C:\Folder1 and a setup with version 13.0 is to be installed in the folder C:\Folder1 then the setup of version 13.0 should uninstall 12.0 version silently and install the latest version 13.0

2. If an application with version e.g. 12.0 is installed at C:\Folder1 and a setup with version 13.0 is to be installed in the folder C:\Folder200 then the setup of version 13.0 should install the latest version and also retain the version 12.0

Things I have tried :

1. If I use the upgrade code method to uninstall the previous version then the uninstall of previous versions will happen even if the previous version is installed anywhere on the system.

2. Using custom action - create a vbscript to read the installed products using WindowsInstaller.Products data and using the Product code created a command to uninstall the application using "msiexec.exe /x ProductCode"

   • This custom action when added in the "Before File Transfer" section in install shield project, gives a pop-up that "The application is installing the version and to wait till it has completed the process".
   • The "Wait for Action" property for the custom action is set to Yes.
   • I tried setting it to "No" as well still same pop-up appears.
   • If I add the custom action in the section of "After setup complete Success Dialog" in install shield project, then both versions are installed and after the vbscript executes, it does uninstall the previous version. The problem with this approach is, when I double click on the desktop icon of the application; it starts installing and displays pop-up of the progress of installation. This would be confusing for the customer. So this approach is not suitable.

3. We have not added any data in registry so cannot use the registry method to uninstall previous versions.

This is a very basic requirement for any software, but I am not able to make out how to achieve this. Please let me know if anybody has some pointers.

I have Installshield limited edition 2015 and Visual Studio 2015 Professional.

Seaton

Answer 1

This actually is not a "basic requirement for any software." The basics are if a ProductCode/UpgradeCode is installed upgrade it.

For point 2 you're getting the pop-up because you're trying to run 2 MSI ExecuteSequences at the same time. If you'd like to continue down this road you'll have to move your uninstall action to the UISequence. Beware that silent installs will not run this action since it never hits the UISequence. Also, the better way to head down this road is to build your own bootstrapper (setup.exe) that controls the flow of uninstall/install.

Saviour

Answer 2

You can't do that because an upgrade (a major upgrade) MSI doesn't care where the previous version of the product is installed. An new MSI with an UpgradeCode (and a few other details) will upgrade an existing product that matches, uninstalling that older product wherever it's installed.

Some Issues (not a complete list):

1. If you want to install another product and NOT upgrade the existing product then you need an MSI that (for example) has a different UpgradeCode or doesn't do a RemoveExistingProducts.

2. Your MSIs (old and new) need to set ARPINSTALLLOCATION, so you can ask where they are installed. That lets you compare install locations (but IMO not an ideal solution).

3. There are issues such as whether the two separate installed products now have the same shortcuts in the start menu, whether there are any shared files in common locations, whether there are any non-shareable items (service names, global event names etc).

4. There are also maintainability issues, such as how to upgrade or patch two almost identical installed products.

Anyway, I would simply ask the user if they want to an upgrade or a side-by-side install, rather than base that decision on a choice of folder (which seems IMO an unusual side effect of choosing an install location).

The general choices are probably based on having a condition on the RemoveExistingProducts action, based on a command line property or other mechanism. Or, depending on maintainability requirements you could change the upgradecode (with a transform on the command line) so that the upgrade doesn't occur. It's not clear to me that detecting the install location of the previous MSI in the browse folder dialog of the new install is straightforward.

Pyotr

These scenarios really don't work well with MSI, do they? I hope future deployment technologies do better. I'm adding some information on the instance transforms concept with my answer - even though I dislike that concept a lot. Not sure what your sentiments are in that regard. It feels like leading people astray. – Duo

Answer 3

I am afraid MSI does not lend itself too well to this sort of scenario - as you have discovered.

• Is this a corporate software, or is it for general, large-scale distribution?
• What is the purpose of this multi-instancse approach? Does this MSI effectively install two different versions of the same application?

Instance Transforms: I suppose you could investigate the instance transforms concept. It is intended to allow multiple installations, but I dislike the concept and have never used it actively. I am hence not able to give you the inside story of limitations and gotchas - sorry - maybe someone else can illuminate?

As PhilDW states you can use another upgrade code for the newest MSI, and then install side-by-side with the old installation. Beyond what has already been mentioned you would also need to change all component GUIDs for the new package. WiX allows component GUIDs to be auto-generated based on destination path, but not so for Installshield. The instance transform should be possible to use to install side-by-side without changing all component GUIDs - I believe.

App-V: If you are in a corporate setting, and if I had enough experience, I would also recommend that you check out App-V packaging (virtualization). This allows isolation of applications so multiple versions can run side-by-side. But again, I am not the right guy to give you the inside story. I know there are a number of limitations, but can't elaborate with real-world experience.

Setup.exe Launcher: If your application gracefully handles multiple instances without clashing shortcuts and service name etc... (like Phil describes), then you could install all new versions side-by-side and never uninstall older versions by default via the upgrade table. You could then handle the uninstall of previous versions manually in your setup.exe launcher (if any). I suppose you could use the instance transform concept to install new versions, or you could re-create your setup for each new version with all new component GUIDs and product, package and upgrade GUIDs.

Legacy Installscript Project: I suppose you could abandon MSI and use a legacy Installscript project to deploy your application. I would not recommend this since such projects are problematic for reliable remote management and silent running (both for install and uninstall).

---

Some links for safekeeping:

• WiX - Doing a major upgrade on a multi instance install
• I want to install an MSI twice
• Disable repair mode and upgrades in wix installer

Chorea