Edited by maxk, 27 January 2015 - 21:00.

Major Upgrade Error 1722
Posted 27 January 2015 - 20:59
Posted 28 January 2015 - 12:52
A major upgrade runs the installer of the old version in uninstall mode. Does Install_2 uninstall sucessfully on its own?
I question your design. If you wnat to update install_1 then you should update it's install package and run it in update mode. Don't use a new installer to replace files that belong to another package.
Stefan Krüger
InstallSite.org twitter facebook
Posted 28 January 2015 - 17:47
Hello Stefan,
Install_2 uninstalled fine (I think). When I get an error, install_2 was removed on the Program and Features list (In Control Panel) and version in the registry.
Any other places to check?
Interestingly, if I don't use the install_2 upgrade code in the install_3 major upgrade, I don't get an error but install_2 doesn't get removed on the Program and Features list.
I typically create a new install but would love to try your way.
When you said "update its install package and run it in update mode", does it mean to either run it as a minor or major upgrade from Install_1 package?
Thanks,
Maxk
Posted 29 January 2015 - 01:40
In my practice, I author all my installers to be Major upgrades. This allows for design flexibility like moving files, components, and features. They work like a full install and depending on how you author them, will upgrade a previous one. I have found that strict versioning rules must be followed in order for a major upgrade to work as intended with default options but if you remove the previous version early enough then there are no hiccups along the way.
This is how I do it.
1. Pick and never change the Upgrade Code. (you should keep the one with Install_1)
2. In the upgrades view, add a new major upgrade item. Name it something if you wish.
3. Select "Products sharing my upgrade code" and "Any earlier version" radio buttons
4. On the advanced tab, make sure maximum version is "***ALL_VERSIONS***
The root of the upgrades tree view shows you options for how the upgrade will work. These radio buttons basically move the "RemoveExistingProducts" custom action around in the Execute sequence.
In order for me to make sure that the previous version is removed before the new version is installed, I manually move this CA to after ValidateProductID.
This is a little inefficient and if there are any errors installing the upgrade, your users are left with nothing installed. In my experience, these are corner cases and not likely to happen.
The reason I place the action here is to come before the Costing steps. These steps define what parts of the new installer are going to get installed. There are a number of instances where a .Net assembly or C dll have the same version numbers. This results in the binaries getting removed and never installed at the end if Costing is run. It would require a repair or a reinstall to fix the problem.
Hope this helps.
Posted 03 February 2015 - 16:20
Hello deramor,
Thanks for sharing your experience.
Since I needed to create multiple upgrades (critical, maintenance, sp, etc), I’ve always thought that simple is better.
However, after encountering this issue a major upgrade could definitely be a better option and less risky.
For this case, install_1 and 2 are delivered so can't be modified.
I need to work with install_3 to fix this error.
"A major upgrade runs the installer of the old version in uninstall mode"
How do I check this or any way to modify this?
Thanks,
M
Edited by maxk, 03 February 2015 - 16:22.
Posted 03 February 2015 - 19:23
When you said "update its install package and run it in update mode", does it mean to either run it as a minor or major upgrade from Install_1 package?
Both is possible.
"A major upgrade runs the installer of the old version in uninstall mode"
How do I check this or any way to modify this?
During a Major Upgrade, the msi of the old version is essentially run with REMOVE=ALL by default. You can modify this (n the new version) by defining the features (of the old version) that should be removed, in the Advanced settings of the Major Upgrade item. However, if you don#t fully uninstall the old version, it's entry in Programs and Features will remain.
Stefan Krüger
InstallSite.org twitter facebook
Posted 05 February 2015 - 17:34
I believe if you author a Major Upgrade item for each Upgrade Code you have in the field, you should be able to remove the released installers. To fix this going forward, I would author a Major Upgrade item with your current Upgrade Code (and never change it) to keep removing older versions going forward.
I don't think the order is very deterministic so if you have an Uninstall order dependency, things could get a little complicated.
Is there a reason you want to remove only some parts of your old installer?
"A major upgrade runs the installer of the old version in uninstall mode"
How do I check this or any way to modify this?
In order to check if the uninstall worked, you can look at the add/remove programs view to see if your entry was removed.
Posted 06 February 2015 - 16:56
Thanks Stefan!
I definitely plan to use a major for all upgrades in the future.
Because the install_1 wasn't stable and was using a very old installshied, I just decided to use this path for install_2.
Now install_3 is cleaned up (codes, binaries, CA, etc) with a newer installshiled.
I think install_3 moving forward should be more stable.
I didn't want to remove only some parts. I wanted to remove everything (install_1 & 2) while running install_3 but it's giving me an error 1722.
Thanks deramor!
Posted 07 February 2015 - 00:53
Is this on Win7? Stopping a service requires admin rights. (I think).
Make sure you are properly elevated.
Posted 10 February 2015 - 16:53
I have no problem stopping/starting a service which is a part of custom action in install_2.
The problem is that install_3 is trying to read a install_2 custom action when install_2 is already uninstalled.
Thanks.
Posted 10 February 2015 - 19:08
It sounds like your use case will not allow you to do what you want. If you need Install_2 present to run Install_3 then I would redesign Install_3 to not have this requirement.
Posted 10 February 2015 - 23:26
Hi deramor,
I think you misunderstood a little bit.
Install_3 is a major upgrade and both install_1 and 2 uninstall fine during install_3.
Again, the problem is that during install_3 installation (after uninstalled sucessfully both 1 and 2), it's trying run a ca from install_2.
Posted 11 February 2015 - 00:31
Can you look at your CAs and see any that look suspect? I'm being intentionally vague here since I don't know of any way to run a CA from another installer. If there was one, it certainly wouldn't be done by accident.
Can you provide a list of the CA types in order of their execution?
Example:
Set Directory
Set Property
Installscript CA
etc...
Posted 12 February 2015 - 19:55
Edited by maxk, 12 February 2015 - 20:00.