I wouldn't do 3. It just sounds messy. You could also consider shipping a patch for Add-on 1.0 to fix it.
PS: This is why you should always ship an upgrade of your v1 product before you ship v1. <smile/> On Wed, Apr 25, 2012 at 5:03 PM, Daetrin Ungashak <gfin...@gmail.com> wrote: > A long time ago our company released a product, let's call it Product > 1.0. A little while later we released an add-on, let's call it Add-On > 1.0. > > Now we are releasing Product 1.5. However we decided that for this > version Add-On 1.5 would be a subfeature of Product 1.5 rather than a > separate install. > > Everything went great until we tried to install the complete package > on a machine that had both Product 1.0 and Add-On 1.0 installed. > Product 1.0 was replaced with 1.5, but although Add-On 1.5 was > installed Add-On 1.0 remained on the machine as well. After a couple > seconds we had the "well duh!" moment of realizing that obviously > Add-On 1.0 had a different UpgradeCode. > > We added the second UpgradeCode to the 1.5 installer and everything > seemed to be going fine. It uninstalled Product 1.0, but then when it > tried to uninstall Add-On 1.0 it logged the following: > > Action start 14:52:14: ScheduleReboot. > DEBUG: Error 2623: Calling ScheduleReboot from a multi-package > transaction is not supported. > MSI (s) (48:E8) [14:52:21:134]: Product: Add-On -- Internal Error 2623. > [...] > Action ended 14:52:21: ScheduleReboot. Return value 3. > Action ended 14:52:21: INSTALL. Return value 3. > > and "shortly" thereafter: > Action ended 14:52:21: RemoveExistingProducts. Return value 3. > Action ended 14:52:21: INSTALL. Return value 3. > > and thus complete failure of the entire installation. > > We're already passing in REBOOT=ReallySuppress to the msi, however > that value is not being passed to the old installers by the > Upgrade/RemoveExistingProducts action, and a little research seems to > indicate there's no way to do so. I did find a blog post from Rob > Mensching last year describing how to pass property values using > registry keys in such situations, but it seems that would have > required us to know about the issue when writing the installers for > Product 1.0 and Add-On 1.0, and it's a little late for that now. > > Luckily we are using our own inhouse bootstrapper so we can use > multiple steps to solve this issue in a number of ways. > > 1: Split it up into two separate installers again, each of which will > upgrade one of the old items. This would be simple, but would be > moving against the direction we want to take the product in and would > perpetuate the problem into the future. > > 2: Use the old product codes to uninstall them via MSIExec > programmatically (using silent mode and REBOOT=ReallySuppress of > course) before running the main msi. > > 3: Create two "fake" msi's which contain no elements but that that we > can run before the "real" msi to "upgrade" both products to version > 1.0.9. Hopefully that would allow us to upgrade the empty 1.0.9 > version to 1.1.0 in the real msi without running into the required > reboot problem. > > Are there any obvious roadblocks to options 2 or 3 that i haven't > thought about yet? Or is there some tricky way to get around the > ScheduleReboot action in the chained RemoveExistingProducts actions? > > Thanks! > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
