Minor Upgrade Custom Sequence

[mperkins]

Hello all. I am very new to IS and I am trying to add upgrades to a setup.exe installer for an internal tool. What has happened in the past with this tool is that upgrades were disabled and the user was notified that they must uninstall manually before reinstalling a newer version.

What I am trying to do is have IS build an installer that automatically does a complete uninstall before reinstalling. However, IS tells me that the only way I can do this is with a major upgrade (which requires changing the product code). We want to do this for every installation and not just for major upgrades.

Is there a way to always do a complete uninstall before the standard install sequence, or is there a custom sequence or a command that I can call from a script, during the setup process?

As another possibility, I see that the uninstall from the Start menu simply invokes the MSI executable with '/x {product code}'. Can't I just forcibly call this at the beginning of the installer?

Any help would be greatly appreciated.

Mike
:confused:

[Kelter]

Calling msiexec.exe within an installation is not recommended. You'll probably get an error saying something to the effect of "There's already a setup in progress. Please complete the current setup first..."

What you want is the behavior of a major upgrade during a minor upgrade. That's perfectly valid. Simple generate a new product code (bu keep the same upgrade code!) for each minor release, and create a major upgrade item in the upgrades tab.

[mperkins]

You are correct. I want to perform a major upgrade uninstall during a minor upgrade.

Unfortunately, my lead does not want to change the product code for say 4.1.0 to 4.2.0. The IS documentation recommends that you only generate a new product code for major releases (3.x.x to 4.x.x).

I just don't see why IS makes this such a black and white choice. Why can't I select an option to do a complete uninstall before any kind of (re)install...no matter if it is a major or minor upgrade?

[Kelter]

Actually, the IS documentation doesn't un-recommend the major upgrades in any event, they only un-recommend the minor and small upgrades when they are not appropriate as per the help topic "Major Upgrade vs. Minor Upgrade vs. Small Update."

As a criteria for doing a major upgrade (which is to say "a criteria for changing the product code") is that you are making changes significant enough to warrent full uninstallation of the old version. So just to invert the previously implied causal relationship: if you need to fully uninstall the program before installing the new one, you want the behavior of a major upgrade, therefore, you want to generate a new product code.

There's really no overhead associated with incrementing a product code. As a for-instance, we have a project that is built in several configurations to create a couple of different installations from a single project. Some of them are sold seperately, and could be installed at the same time. For this reason, those two groups have two different upgrade codes. Also, our evaluation configurations have the same upgrade codes but different product codes from the release versions. Although they are the same version number, we want to initiate a full uninstall of the evaluation before installing the release.

Maybe that'll help you sell the idea to your lead.

---------

GUIDs are free!!!!!

[#5]

Additionally, IS makes it a black and white choice because it is a black and white choice. There are no semi-upgrade types, everything is either one thing or another.

While right now, that's a bit of a tough situation because you're somewhat still trying to grasp Windows Installer, later on it's a boon. It makes setup development much easier and more clean.

Your users and support department will appreciate the consistent results from your installers.