I don't like ALLUSERS=2 because it's indeterminate depending on the user
privileges. A major upgrade won't upgrade unless the incoming product
matches the installed product's ALLUSERS value. If an administrator
installs the original version it will be per-machine; if a
non-administrator does the upgrade you get two versions installed
because the incoming product will be per-user. Per-machine won't upgrade
per-user either. So check that your incoming product matches the
installed product's per-user/per-machine state.
I believe RemoveExistingProducts is best sequenced just after
InstallInitialize for robustness. The documentation for sequencing after
InstallFinalize talks about this being the most efficient placement,
although it often produces surprises when (say) uninstall custom actions
run during the REP uninstall while the new product is already installed
(I can't remember how many times people have accidentally deleted
just-installed files and web sites this way). The documentation also
says "If the removal of the old application fails, then the installer
only rolls back the uninstallation of the old application." which means
you end up with both old AND new products on the system when the
uninstall fails and rolls back. When it's in the transaction sequence
you at least get a safer result, which is that if the uninstall fails
then the complete upgrade rolls back and leaves you with the original
product on the system. So it's possible that your REP failed silently
and left you with both products installed.
Either way, a log will show what's happening, FindRelatedProducts will
tell you if it detected the older version.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew
Sheets
Sent: Thursday, August 16, 2007 7:47 AM
To: Bob Arnson
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Performing both New Installs and Upgrades with
aCommon MSI
Thank you for the reply. I have removed the OnlyDetect attribute from
the UpgradeVersion element. When moving from one version to the next, I
perform the following changes:
* Product Version number
* Product GUID
* Package GUID
All other GUID's remain unchanged.
Based on http://support.microsoft.com/kb/870714, I made the "later"
scheduling of RemoveExistingProducts be after InstallFinalize in the
InstallExecuteSequence. According to
http://msdn2.microsoft.com/en-us/library/aa372038.aspx, InstallFinalize
appears by default to be the last action in the InstallExecuteSequence.
After implementing those described changes, the generated MSI can both
upgrade an existing installation (while preserving existing data and not
firing the uninstall actions) as well as load a new install; however,
multiple entries are still generated in Add or Remove Programs.
I have attached the updated wxs file. Have I missed something, or is
there a better time to schedule the RemoveExistingProducts action?
Thank you,
Matthew
________________________________
From: Bob Arnson
Sent: Wednesday, August 15, 2007 2:01 AM
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Performing both New Installs and Upgrades with
a Common MSI
Matthew Sheets wrote:
Major Upgrade
Advantages
* Can set the UpgradeVersion OnlyDetect attribute to prevent a
clearing out of data during an upgrade uninstall/reinstall
Issues
* Creates multiple entries under Add or Remove Programs
If you use OnlyDetect, you're not creating a major upgrade; that's why
you have multiple entries in ARP. As the name implies, OnlyDetect
doesn't remove the previous version. If you keep your component GUIDs
stable and schedule RemoveExistingProducts late, then MSI won't
uninstall the component and the WiX custom actions won't trigger
uninstall behavior.
--
sig://boB
http://joyofsetup.com/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
