It turns out, the problem was because I was installing a component based on
the existence of a file on the end users computer, like this.
<Property Id="DEPFOUND">
<DirectorySearch Id="deppath" Path="[SystemFolder]">
<FileSearch Id="depfile" Name="depfile.dll" />
</DirectorySearch>
</Property>
and then later
<Feature Id="SetDEP" Title="Enable DEP" Level="0">
<ComponentRef Id="DepComponent"/>
<Condition Level="1">DEPFOUND</Condition>
</Feature>
Unfortunately, not marking the property secure caused the behavior shown in
my previous messages.
Thanks to Bob, for this
http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/
which led me in the right direction.
I had been using a similar idiom for desktop shortcuts on a tick box, but
they didn't seem to need secure. Perhaps it's because they defaulted to on
instead of off.
Anthony Wieser
Wieser Software Ltd
----- Original Message -----
From: "Anthony Wieser" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, October 30, 2007 11:19 AM
Subject: Re: [WiX-users] Maintenance modes (Might be related to old
UACPrompt Required thread, April 2007)
> 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
-------------------------------------------------------------------------
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
