This is all good information, but I want to get back to the original question at hand for future onlookers seeking a solution (or understanding of their problem).
The logical containers are as follows: A bundle consisting of several .msi packages. Each package has upgrade rules that in this case are specified by the MajorUpgraded element. The scheduling of the upgrade is specified by the "schedule" attribute. You can read more about the schedule order here:<br/> http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html <http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html> <br/> The bundle itself also has upgrade features. Typically speaking the bundle is a custom bootstrapper application and it is the only thing I am allowing to show up in add/remove programs. I specifically disallow each of the .msi packages from creating entries in add/remove programs. Upgrades require that the first three digits of the dotted-quad evaluate to a larger value than the previous installation. For major upgrades to work with msi packages it's suitable to specify the Product Id="*" such that it's unique per build, and you must keep the UpgradeCode the same for the lifecycle of the software that you want to maintain upgrades for. Also note that perUser cannot update perMachine and visaversa. The original question was based on the observation that the default behavior for an upgrade to one of the msi packages within an bundle (new msi version AND bundle version) is to schedule the RemoveExistingProducts afterInstallValidate. When it does this the documentation says that scheduling removes the installed product entirely before installing the upgrade product. However, that is NOT what I am observing in the logs. What I am seeing is that it installs the new version then following successful installation removes the old version. My msi package being upgraded installs a new driver that is currently loaded. The observed default behavior was installing the new driver files, then uninstalling the device (which leads to subdevices being removed). This requires a reboot at which point the driver files exist and the enumeration process of the subdevices does not take place. In order for that process to take place a the order needs to be uninstall/install. I was asking how to force that to happen. For future readers of this post I would suggest changing the schedule of RemoveExistingProducts and checking the log file to make sure you are getting what you need. For my case, the order that made the PnP manager happy was to schedule afterInstallExecute. This works because the installation happens over top of any existing installation and does not require that the device goes through the removal process. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Force-a-MajorUpgrade-to-do-complete-uninstall-BEFORE-new-install-tp7597686p7597720.html Sent from the wix-users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
