Advanced Installer Uninstall Previous Version

[Kayla Munl]

Ineed a sanity check and some help here. I'm not extremely technical (such as a programming degree) but I'm in charge of the installers for my company. We've been using InnoSetup for over 10 years, and SetupBuilder for 6 years, and I've never had an issue with installing over the product's files with patches or feature updates...until I was tasked with migrating all our product installers over to Advanced Installer (called AI from here).

"Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel."

And I've looked through many forum posts about similar issues, and their answer is the same: I need to change the Product Code. BUT, as I research this outside AI's site, the answer is the opposite: Never change the Product Code unless the changes are major enough to warrant considering it a separate product (like Microsoft Word 2003 to 2007), and don't just change the Upgrade Code for minor or patch updates (because these aren't upgrades to something like a higher edition of our product). AI's support says this is because of Windows Installer not allowing the same Product Code twice, as previously stated, but I'm not installing a new product; I'm installing an update of the same product. All that's changed is some files and the version number (2nd or 3rd segment). And again, no other installer program has had this problem.

So here's my question: How do I work around this so I can just run an older version, newer version, or even the same version and let it overwrite the files? Or if I'm stuck with this, is there a way to always uninstall the detected installation so it can install fresh each time? InnoSetup and SetupBuilder don't even uninstall the existing product, they just overwrite, so I'm vexed by AI's odd paradigm.

If you want one .msi package to be able to upgrade another .msi package just by double-clicking, Windows Installer supports that only with major upgrades, which require you to change the product code and increment the version. Don't let the word major connote size of scope. As I said a very long time ago:

After some googling I came up with a configuration that should allow me to install only newer versions of my package (which it does) while replacing the older, already installed version(s) (which it doesn't)

Failed Major Upgrade: When you see two entries in Add / Remove Programs your major upgrade has failed (generally). You need to fix the configuration of the Upgrade table. See likely causes listed below.

Advanced: It is even possible to combine the above "convenience element" for simple major upgrade configuration with old-style elements for total control of Upgrade table content. Samples here.

Mismatched Upgrade Code: There might be a mismatch in the upgrade codes between the old and the new version of the MSI so the products are not identified as related. This should leave two versions installed afterwards (uninstall of old version never happened).

Missing Upgrade Code: Just adding that it is possible for the upgrade code to be missing from the Product element. This is generally an error, unless you want to do something specifically weird.

Missing MajorUpgrade Element: The whole Major Upgrade element can be missing and no Upgrade element present. The latter is for manual configuration of major upgrades, the former for "auto-magical" implementation of typical major upgrade scenarios. Sort of "best practice".

Dangling Version: It is also possible that your WiX markup is fine, and you have a dangling older version that was never correctly configured, if so uninstall it manually and try again or try on a clean virtual. If you auto-generate the product GUID you can end up with several versions of your product installed at once if the major upgrade isn't set up properly. You can normally uninstall all these versions from the Add / Remove program applet. You can also find the product GUIDs involved and uninstall via the mechanism you choose: Different ways to uninstall MSI files.

Installation Context: MSI files can install per-user or per-machine. If you have an installation per-user and then run a per-machine installation it will not detect the previous version. Do you have any hard coded references to ALLUSERS in your package?

SecureCustomProperties: Quickly - while I remember - in secure environments (corporate environments with users running without admin rights) you need to add the ACTION property from the Upgrade table to the list of secure properties (properties allowed to be passed to deferred mode).

Package Code: A very special case I have seen is when the new package has the same package code as the old one (or an existing installed package). This is an extreme design error and must not occur. Always auto-generate the package code, it is the right way to do things. Windows Installer will treat the two packages as identical by definition (as opposed to actual fact - you won't believe the X-Files that can result).

A major upgrade is essentially an uninstall of the older version and an installation of the new version with a number of scheduling options for the order in which actions take place (install new first, then uninstall old or vice versa).

WiX Learning Curve: Suggest using some samples to help speed up the learning process. The only thing that really helps? Here are some WiX Quick Start Suggestions. There are sample links in there.

Minimal WiX Sample: There is this old sample: Transparent Aluminum. Essentially a walk-through of how to use Votive to create a WiX-based installer. It includes a major upgrade element. I believe this simple configuration adds the protection against downgrade that you seek:

Advanced: Here is a demo of an advanced way to configure major upgrades using a combination of the convenience element "MajorUpgrade" and the older "Upgrade" elements (that allow you more fine-grained control of the resulting Upgrade table):

I think that I finally successfully uninstalled the five previous versions whose obsolete traces were still on my system after upgrading to the 2.x version.

However, I have had to fully chronologically reinstall whole these five version, because the "Remove/Repair/Reinstall" feature seems to not work at all. And of course, I have had to uninstall first the last 2.x version I was using.

So, in my case, I finally had to:

Hi! I've talked with one of our SourceTree Windows developers and he told me that Windows keeps a copy of the installer on the hard drive and when 'uninstall' is triggered in that dialog, Windows runs the installer with the 'uninstall' flags.

However Windows, or rather 3rd party apps, have a habit of seeing the cached installers as fair game when trying to clear disk space and you end up in that situation where the uninstall fails because it can't find the cached installer.

The best option is to download the original installer which, when run, should detect the old install and offer the Remove/Repair/Reinstall option. You can then choose the 'Remove' option and it should clean up.

Hi! It could be that the uninstall hasn't cleared all the registry settings. You can go to Control Panel > Programs > Programs and Features and make sure the older SourceTree versions are removed, then reboot your system to make sure the uninstall is complete.

That dialog is shown in SourceTree when 2.x runs and it finds registry entries referring to prior versions, if you confirm you have uninstalled those, then you can safely check the 'Don't ask me again' option and you won't be prompted with that message again.

As you build new versions of an installation package by using one tool or another, the new versions should be able to upgrade the older versions (remove them before the installation). Depending on the old package, there are three possible scenarios for upgrading it:

In this case, you can follow the steps explained in the Upgrades page. Note that you can choose between the "Automatically upgrade older product versions" and "Allow side by side installs of different product versions" options.

Since the old package is MSI-based, it most likely has an Upgrade Code. This code can be used in the "Upgrades" page in order to set the new package to upgrade the old one. With this method the old package is uninstalled automatically and silently right before the new installation starts.

Another method is to use a custom action like explained in the Uninstall another MSI when my product is uninstalled How-To. In this case the custom action will not prompt the user (it will still be executed after "Install Execution Stage" -> "Finish Execution" -> "InstallFinalize")

When you need to upgrade an installation package which is not MSI-based you can use a custom action. If the old package has an Uninstaller, you can use that as a target for the custom action. Since the old product should be removed before the new installation takes place, the custom action can use the condition NOT Installed and be scheduled straight under the "Preparing" action group.

You can still create an uninstall mechanism (e.g. uninstall script) and use a custom action, even if the old package doesn't come with its own Uninstaller. However, when you create the uninstall script you need to take into consideration that the custom action must remove all the resources (files, registry entries etc.) created by the old installation. The logic is still the same, the only difference being the custom action points now to the uninstall script you created rather than the vendor uninstaller.

This is a new one. Was a previous version of the software installed on a removable drive or a mapped network drive at some point? Also, did you manually uninstall any Microsoft Visual C++ Redistributables recently?

3a8082e126