Re: [WiX-users] Performing both New Installs and Upgrades with a Common MSI
The issue with the upgrade failing shows here in the upgrade log:
Action start 9:23:46: FindRelatedProducts.
MSI (c) (78:98) [09:23:46:746]: FindRelatedProducts: current install is
per-user. Related install for product
'{0CF15655-D694-4EF7-9EFB-CBAE6F1C4C55}' is per-machine. Skipping...
Action ended 9:23:46: FindRelatedProducts. Return value 1.
The first product was installed per user, the upgrade is coming in as
per-machine.
ALLUSERS=2 is not a real value. It means do a per-user install if the
installing user does not have administrator privilege otherwise do a
per-machine install. In your case, the original install may have been
ALLUSERS=2 by a non-administrator, resulting in a per-user install. The
upgrading install can have ALLUSERS=2 also, but with administrator
privileges it becomes a per-machine install that won't upgrade the
per-user one. Better to get out of the business of ALLUSERS=2 and decide
whether you want per-machine or per-user and set ALLUSERS accordingly.
Phil Wilson
From: Matthew Sheets [mailto:[EMAIL PROTECTED]
Sent: Monday, August 20, 2007 7:10 AM
To: Bob Arnson; Wilson, Phil
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Performing both New Installs and Upgrades with
a Common MSI
Thank you for the feedback. Interesting observations on the ALLUSERS
property-it appears to hit on an issue. The MSI will be executed under
an administrative account, but users in the Windows Users group will
need to be able to run the program once it is installed. I did a dark
of an MSI generated by the Visual Studio 2005 setup project, and the
InstallAllUsers project property appeared to correlate to the ALLUSERS
MSI property. Thus, ALLUSERS=2 was incorporated in a similar fashion in
the WiX file.
In reviewing MSI installer logs from previous install/upgrade attempts,
I had observed that somewhere along the line, ALLUSERS comes up with a
value of 1. This, despite the fact that the initial install set
ALLUSERS=2 and the upgrade also set ALLUSERS=2. The goal is to install
all Start Menu and Desktop items under All Users (not yet
implemented); apart from that, ALLUSERS=2 doesn't have any other
significance (at least that I know of) in this particular WiX file.
That ALLUSERS property change from 2 to 1 can also be seen in that
attached log files.
As a test, I commented out ALLUSERS-related elements in the WiX file.
Add or Remove Programs now contains only a single program entry (even
after performing upgrades), but properties such as ProgramMenuFolder and
DesktopFolder now point to that of the current user instead of All
Users. Nevertheless, this seems to be a step in the right direction.
I found a blog post at
http://www.rikware.com/WebLog/Oct122006_Experimenting+with+WiX.html
indicating an ALLUSERS value of 1 achieves the All Users folder
result; would it be appropriate to use Property
Id=ALLUSERS1/Property instead of the darked Visual Studio value
of 2? Testing using this value appears to achieve the desired results
for non-duplication of Add or Remove Program entries, use of All Users
folders, preservation of existing data during upgrades, and use of a
common MSI for both new installs and upgrades.
Here is a description of the attached files (all logs created with
option /lvap)-
* ManagedCASample.wxs - the WiX file with ALLUSERS property
elements commented out
* WixAllUsersSetup.log - clean install, with ALLUSERS elements
included
* WixAllUsersUpgrade.log - upgrade install, with ALLUSERS elements
included
I have more logs I could post, but I hit a message too large e-mail
rejection from SourceForge when attempting to also include the following
(if any of these might be useful, please let me know):
* WixSetup.log - clean install, with ALLUSERS elements commented
out
* WixUpgrade.log - upgrade install, with ALLUSERS elements
commented out
* Wix1Setup.log - clean install, with ALLUSERS property set to 1
* Wix1Upgrade.log - upgrade install, with ALLUSERS property set to
1
Thank you,
Matthew
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Friday, August 17, 2007 10:17 AM
To: Wilson, Phil
Cc: wix-users@lists.sourceforge.net; Matthew Sheets
Subject: Re: [WiX-users] Performing both New Installs and Upgrades with
aCommon MSI
Wilson, Phil wrote:
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.
Agreed -- major upgrades shouldn't use ALLUSERS=2. For that matter, most
products shouldn't use ALLUSERS=2.
I believe RemoveExistingProducts is best sequenced just after
InstallInitialize for robustness.
I generally agree, though in this case it was specifically to prevent
the assets behind components from being removed if they don't have
explicit upgrade support.
Matthew, logging will indicate how MSI
Re: [WiX-users] Performing both New Installs and Upgrades with a Common 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/ ManagedCASample.wxs Description: ManagedCASample.wxs - 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
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
[WiX-users] Performing both New Installs and Upgrades with a Common MSI
Hello, WiX 2.0 is being considered for use in a project since it is stable and essentially final (escrow). The target systems are Windows XP and Windows 2003. The objectives for setup are as follows, but there have been issues attempting to meet these: * Single setup MSI that will dynamically handle both new installs and upgrades * Ability to perform configuration on new install (e.g. SQL Server, IIS, Permissions) * Ability to persist configuration when upgrading (e.g. database) * Ability to perform cleanup on uninstall (e.g. drop database, force deletion of installation directory [even if new files/folders have been added], remove virtual IIS sites/applications) Background Various searches have been done related to these issues. Some of the more informative web pages found include the following: * http://support.microsoft.com/kb/555184 * http://www.tramontana.co.hu/wix/lesson4.php * http://sourceforge.net/mailarchive/message.php?msg_id=a2e077d70604031123 w3ee591c7ma684a8449b0a2ddb%40mail.gmail.com (appears very similar to my issue, but doesn't seem to solve this particular case) * http://blog.opennetcf.org/ncowburn/2005/01/04/UsingCustomActionsWithWiX. aspx Methods Attempted Custom Actions Advantages * Can detect in code whether each install, commit, rollback, and uninstall action is occurring as part of a new install, reinstall, upgrade, or removal. Disadvantages * Have to write code (sometimes a lot) for what would otherwise be simple WiX elements (e.g. database, IIS, permissions, etc.) Issues * There is a major custom actions bug-during an upgrade, old actions are executed instead of the new ones. This has been replicated with both Visual Studio 2005's default installer AND WiX. See Microsoft KB at http://support.microsoft.com/kb/555184 (note that no resolution is provided). Minor Upgrade Issues * Have not found a way for the same MSI to handle both new installs and upgrades * Property arguments have to be provided on the command line when the upgrade is minor, but REINSTALL and REINSTALLMODE cannot be present when it is a new install. 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 To try to get started, I have been building off a sample WiX project available for download from http://blog.opennetcf.org/ncowburn/2005/01/04/UsingCustomActionsWithWiX. aspx. I have attached the .wxs file with which I have been working. Given the stated objectives, is it possible to generate such an MSI with WiX? If there were a way to prevent the duplicate Add or Remove Programs entries, the Major Upgrade method using OnlyDetect might work. I would appreciate any insight or pointers. Thank you, Matthew ManagedCASample.wxs Description: ManagedCASample.wxs - 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
