I just meant that the component wouldn't be excluded on maintenance if you 
had 'or Installed' regardless of the value of DEPFOUND, but perhaps it 
wouldn't work.

Kelly




"Anthony Wieser" <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
10/30/2007 08:41 AM

To
<wix-users@lists.sourceforge.net>
cc

Subject
Re: [WiX-users] Maintenance modes  SOLVED!






It's not my file.  I'm modifying a registry entry based on whether I find 
a file in the system folder.
 
Anthony Wieser
Wieser Software Ltd
 
----- Original Message ----- 
From: Kelly Leahy 
To: Anthony Wieser 
Cc: wix-users@lists.sourceforge.net ; 
[EMAIL PROTECTED] 
Sent: Tuesday, October 30, 2007 3:18 PM
Subject: Re: [WiX-users] Maintenance modes SOLVED!


Would adding 'Or Installed' to the condition work as well?  Wouldn't it 
then remove the file if it's there, and leave it if it isn't? 

Kelly 



"Anthony Wieser" <[EMAIL PROTECTED]> 

Sent by: [EMAIL PROTECTED] 
10/30/2007 08:00 AM 


To
<wix-users@lists.sourceforge.net> 
cc

Subject
Re: [WiX-users] Maintenance modes  SOLVED!








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: <wix-users@lists.sourceforge.net>
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: <wix-users@lists.sourceforge.net>
> 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
>> WiX-users@lists.sourceforge.net
>> 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
> WiX-users@lists.sourceforge.net
> 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
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



**************************************************************************************
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or 
opinions upon which reliance may be made by the addressee or any 
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries 
guidelines.
**************************************************************************************
-------------------------------------------------------------------------
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




**************************************************************************************
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or 
opinions upon which reliance may be made by the addressee or any 
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries 
guidelines.
**************************************************************************************
-------------------------------------------------------------------------
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

Reply via email to