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
