I took the approach of no longer using the ServiceInstall tag to install the
service. I'm using an evil custom action to call the installed service
executable with a 'register' parameter when the feature is installed, and with
'unregister' when the feature is uninstalled. My desired "upgrades" scenario
(with a new product GUID) is that neither an install or an uninstall will be
triggered.
But with these conditions:
<Custom Action="InstallServiceAction"
After="InstallFinalize">(&Relman4=3) AND (!Relman4=2)</Custom>
<Custom Action="UnInstallServiceAction"
Before="RemoveFiles">(&Relman4=2) AND (!Relman4=3)</Custom>
An "upgrade" with a new product GUID does both the uninstall, and then the
install. Which is odd, since I don't see how both actions can occur unless the
values of &Relman4 and !Relman4 are changing during the uninstall/re-install
process? Here's an example log of my upgrade scenario. The uninstall and
install service actions should never run. Looks like the conditions are each
evaluated twice, which I wouldn't expect.
MSI (s) (44:9C) [22:47:25:874]: Skipping action: UnInstallServiceAction
(condition is false)
=============================
Action ended 22:47:27: RemoveRegistryValues. Return value 1.
MSI (s) (44:60) [22:47:27:671]: Doing action: UnInstallServiceAction
Action 22:47:27: UnInstallServiceAction.
Action start 22:47:27: UnInstallServiceAction.
Action ended 22:47:42: UnInstallServiceAction. Return value 1.
MSI (s) (44:60) [22:47:42:686]: Doing action: RemoveFiles
=============================
Action ended 22:47:42: RemoveExistingProducts. Return value 0.
MSI (s) (44:60) [22:47:42:780]: Skipping action: InstallServiceAction
(condition is false)
=============================
Action ended 22:47:42: RemoveExistingProducts. Return value 1.
MSI (s) (44:9C) [22:47:42:811]: Doing action: InstallServiceAction
Action 22:47:42: InstallServiceAction.
Action start 22:47:42: InstallServiceAction.
Action ended 22:47:58: InstallServiceAction. Return value 1.
Action ended 22:47:58: INSTALL. Return value 1.
Here's my entire sequence:
<InstallExecuteSequence>
<!-- install the service when the state of the controller feature is not
present (2), but the action
state of the controller feature is 3 (present on local computer) -->
<Custom Action="InstallServiceAction"
After="InstallFinalize">(&Relman4=3) AND (!Relman4=2)</Custom>
<Custom Action="UnInstallServiceAction"
Before="RemoveFiles">(&Relman4=2) AND (!Relman4=3)</Custom>
<!-- For upgrades, we need RemoveExistingProducts to remove the previous
version -->
<RemoveExistingProducts After='InstallFinalize' />
</InstallExecuteSequence>
<InstallUISequence>
<Show Dialog="CustomizeDlg" After="MigrateFeatureStates"></Show>
</InstallUISequence>
I'm guessing I just have the wrong condition for my actions, but I'm at a loss
about how to get this right.
Jason
From: Rob Mensching
Sent: Friday, September 21, 2007 6:02 PM
To: Jason Shay; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] WIX to install Services, but upgrade resets
username/password
Nothing like that exists natively in the Windows Installer. You'd need to read
the existing settings then put them back.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Shay
Sent: Thursday, September 20, 2007 16:19
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] WIX to install Services, but upgrade resets
username/password
I've got a component with a windows service executable (it's the Key), and a
<ServiceInstall> tag as follows:
<ServiceInstall Id="ServiceID" Name="BsHost" DisplayName="Service Display Name"
Description="Service Description" ErrorControl="normal" Start="auto"
Type="ownProcess" Vital="yes">
The problem is, when I put out a new version (not an upgrade package, but
"upgrading" via a fresh product GUID), the settings to the service are set back
to default. My desired behavior is that if the user has changed the
Account/Password for the service manually, I don't want to overwrite that.
Ideally, I want something like "if the service already exists, don't change
anything". Note that I can't query the user for username/password, as this
install needs to support unattend, and the user triggering this install doesn't
necessarily know the password that the service was configured to run as (if the
user modified it manually).
Any ideas?
Jason
-------------------------------------------------------------------------
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
