[wix-users] RemoveFolderEx and disabled components

[Rob Mensching]

So is this issue that the custom action isn't adding a full path because you specified a relative path?

_____________________________________________________________
 Short replies here. Complete answers over there: http://www.firegiant.com/

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of Paul Shmakov via wix-users
Sent: Friday, October 19, 2018 3:39 AM
To: wix-users at lists.wixtoolset.org
Cc: Paul Shmakov <paul.shmakov at gmail.com>
Subject: Re: [wix-users] RemoveFolderEx and disabled components

Hello, I should have been more specific about the failure.

WixRemoveFoldersEx does not fail on its own. The installation fails due to the records WixRemoveFoldersEx adds to the RemoveFile table.
WixRemoveFoldersEx usually completes with no side effects if it cannot find "\Foo\".
However, if such a folder exists on the C: drive, i.e. C:\Foo, then WixRemoveFoldersEx finds it and adds "\Foo\" to the RemoveFile table.
And it's CostFinalize who fails, saying:
Error 1606. Could not access network location \Foo\.
Action ended 23:26:20: CostFinalize. Return value 3.

I understand that one should not use relative paths with RemoveFoldersEx. However, if the parent component is disabled, it's kind of safe to assume that it does not matter what is passed as a path to RemoveFoldersEx, because the action should not execute anyway.
But it does execute under the covers.

Thanks,
Paul

пт, 19 окт. 2018 г. в 4:36, Bob Arnson via wix-users
<wix-users at lists.wixtoolset.org>:
>
> The design was that it should log and continue. And as the components propagate to the generated rows, there's minimal value in checking the component state first.
>
> -----Original Message-----
> From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of 
> Rob Mensching via wix-users
> Sent: Thursday, 18 October, 2018 21:11
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Cc: Rob Mensching <rob at firegiant.com>
> Subject: Re: [wix-users] RemoveFolderEx and disabled components
>
> The custom action probably shouldn't fail if the folders are already gone but otherwise the custom action is behaving correctly, assigning the rows to a Component.
> _____________________________________________________________
>  Short replies here. Complete answers over there: 
> http://www.firegiant.com/
>
> -----Original Message-----
> From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of 
> Paul Shmakov via wix-users
> Sent: Thursday, October 18, 2018 4:38 PM
> To: wix-users at lists.wixtoolset.org
> Cc: Paul Shmakov <paul.shmakov at gmail.com>
> Subject: [wix-users] RemoveFolderEx and disabled components
>
> Hello!
>
> WixRemoveFolderEx searches the file system and populates the RemoveFile table even for the disabled components. It's a problem because the path may not exist.
>
> Here's my use case: during the installation I need to delete traces of the previous version of the product that was installed using batch files (not MSI), if it's present.
>
> All the cleaning up is packaged as a Component which has a condition "NOT Installed AND OLDPRODUCTFOUND". The component consists of a bunch of RemoveFile nodes and RemoveFolderEx to delete certain subfolders.
>
> The RemoveFolderEx here makes sense only if the old product is detected (OLDPRODUCTFOUND property). Otherwise there's no meaningful path to search through.
>
> WixRemoveFoldersEx does not check the installation state of the component, nor does it have its own condition. As a result WixRemoveFoldersEx always executes and tries to search the path that does not exist. And fails.
>
> Here's a snippet:
> <Property Id="OLDPRODUCTFOUND">
>   <DirectorySearch
>       Path="[ProgramFilesFolder]\Company\Product X"
>       AssignToProperty="yes">
>     <FileSearch Name="ProductX.exe"/>
>   </DirectorySearch>
> </Property>
>
> <SetProperty
>     Id="OLDSUBFOLDER"
>     Value="[OLDPRODUCTFOUND]\Foo\Bar"
>     Before="CostInitialize" />
>
> <Component Id="CleanupOldProduct">
>   <Condition>NOT Installed AND OLDPRODUCTFOUND</Condition>
>   <util:RemoveFolderEx Property="OLDSUBFOLDER" On="install"/> 
> </Component>
>
> If the old product is not found, WixRemoveFoldersEx tries to enumerate "\Foo\Bar" and fails.
>
> I'd really appreciate if somebody can explain what I'm doing wrong here or point me to a known workaround.
> The only solution I can think of is to set the property (OLDSUBFOLDER) to some non-existent folder to let WixRemoveFoldersEx fail gracefully.
>
> Wix 3.11
>
> Thanks in advance,
> Paul
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant 
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant 
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant 
> http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/