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