It gets even stranger.
For some reason, it does uninstall properly when I start the msi from an
admin command prompt like this:
msiexec /i setup.msi /l*vx admin.log
but if I start it from a non admin account like this:
msiexec /i setuprip.msi /l*vx nonadmin.log
it leaves behind the items an admin can't remove.
I also notice in the logs, I have these lines in the admin.log file:
MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying CostingComplete
property. Its current value is '0'. Its new value: '1'.
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: BindImage
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: ProgId
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: PublishComponent
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: SelfReg
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Extension
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Font
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Class
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2:
MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2:
MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE property.
Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 'ALL'.
Action ended 10:47:56: InstallValidate. Return value 1.
The non admin log is missing the modify of the remove property.
I'm using an install sequence based on the wix UI specified like this:
<Property Id="WixUI_Mode" Value="InstallDir" />
I also notice that in the admin log I have this:
MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1
because this is the client or the user has already permitted elevation
MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated property
to 1 because the install is already running elevated.
MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding MsiRunningElevated
property. Its value is '1'.
MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged property.
Its value is '1'.
while in the non-admin it says:
*********
MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not required
at this point, product is managed and deployment compliant
**********
MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1
because the product is already installed managed and per-machine
MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser property.
Its value is '1'.
MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated property
to 1 because the install is already running elevated.
MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding MsiRunningElevated
property. Its value is '1'.
MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged property.
Its value is '1'.
So it looks like it won't do it because it hasn't elevated, which makes
sense, because it's a per machine install.
So, it's looking like it's not really a WiX problem, but more of an MSI
problem.
Any ideas?
Anthony Wieser
Wieser Software Ltd
----- Original Message -----
From: "Anthony Wieser" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, October 30, 2007 6:47 AM
Subject: Re: [WiX-users] Maintenance modes
> From: "Richard" <[EMAIL PROTECTED]>
> Sent: Monday, October 29, 2007 9:40 PM
> Subject: Re: [WiX-users] Maintenance modes
>
>
>>
>> In article <[EMAIL PROTECTED]>,
>> "Anthony Wieser" <[EMAIL PROTECTED]> writes:
>>
>>> For some reason my msi file is bringing up the maintenance mode when I
>>> double click it.
>>
>> This means its already installed.
>>
>>> 1. How do I make sure that only remove is supported.
>>> I've already set the property ARPNOMODIFY like this:
>>> <Property Id="ARPNOMODIFY" Value="1" />
>>> but I've done it in a <UI> block. Is that wrong?
>>
>> Put it inside the <Product> tag.
> Turns out I got this from the WixUI_InstallDir.wxs file I based it on.
> The
> property seems to be in the right place when I look at the file in Orcas.
>
>>
>>> Secondly, if this is expected behavior, any ideas why when I click the
>>> remove button, everything in my install disappears, except for the
>>> entries
>>> under add remove programs?
>>
>> It sounds like you've corrupted Add/Remove Programs somehow. You can
>> use the msizap utility to make A/RP "forget" about your product, but
>> use this only as a last resort.
>
> I don't think that's what's going on, because I can still remove the
> program
> from ARP afterwards, even though most of the install is gone.
>
> Trawling through the UI sources, I found this in VerifyReadDlg.wxs:
> <Control Id="Remove" Type="PushButton" X="236" Y="243"
> Width="56" Height="17" Hidden="yes" Text="!(loc.VerifyReadyDlgRemove)">
> <Condition Action="show">WixUI_InstallMode =
> "Remove"</Condition>
> <Publish Event="Remove"
> Value="All"><![CDATA[OutOfDiskSpace <> 1]]></Publish>
> [snip...]
> </Control>
>
> However, the msi documentation says the argument for remove is:
> A string that is either the name of the feature or "ALL".
>
> Does it matter that the case is wrong?
>
>> It could be a problem, but its hard to say without debugging it myself
>> in front of your computer. (And no, that's not an invitation for free
>> consulting :-).
>
> I wouldn't expect that.
>
> Anthony Wieser
> Wieser Software Ltd
>
>
> -------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wix-users
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
