Hi Michael, Thanks a lot for the explanation and for the link. I'll take a look, as this would be the "approved" way of doing this.
If one wants to do that with CA, then the code would be (I'll put the code here for further reference): <CustomAction Id="QtExecDeferred_Cmd" Property="QtExecDeferred" Value='"[SystemFolder]Cmd.exe" /C del /Q "[INSTALLLOCATION]momo.txt"'/> <CustomAction Id="QtExecDeferred" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="ignore" Impersonate="no"/> <InstallExecuteSequence> <Custom Action="QtExecDeferred" After="RemoveExistingProducts">REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE</Custom> <Custom Action="QtExecDeferred_Cmd" Before="QtExecDeferred">REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE</Custom> </InstallExecuteSequence> Thank you, MeCoco On 11/29/2010 4:02 PM, Michael Urman wrote: > The trick here is that in the working case, the component is never > uninstalled. With REP after InstallFinalize, the new install > increments the component's reference count, possibly installing > updated contents. Then REP uninstalls the earlier version, which > merely decrements this component's reference count. You can verify > this by examining the differences in the verbose logs for each > scenario. > > If you want to find an "approved" way to handle this, perhaps you > should consider the approach in Bob's Semi-custom actions article > (http://www.joyofsetup.com/2007/07/01/semi-custom-actions/) by > conditionally writing to the remove file table. I'm personally torn as > to how great an idea it is, because the difficulty of getting the > RemoveFile table entry correct is nearly as difficult as getting a > file removal correct. > > However one last comment: this whole approach has problems. If you > ever use an Upgrade table entry to remove this product from from a new > unrelated product, it will then likely leave this file behind when it > should not. A pity there's no great way to handle such scenarios. > > On Mon, Nov 29, 2010 at 08:36, MeCoco<vcotirl...@hotmail.com> wrote: >> Hi Michael, >> >> Thanks for your answer. >> >> > Because of this, the premise that a component condition can prevent >> the RemoveFile table entry from executing during uninstall is flawed, >> >> I wouldn't have expected that, because of: >> >> 1) The code works as expected when I have REP after installFinalize, >> meaning the file is deleted only when uninstall, not also update. Why is >> then the code working as I was expecting when REP is after >> InstallFinalize? In that case the file should have also been removed as >> part of the component-uninstall right? >> >> 2) I was sure, one can accomplish my requirement (delete a file created >> by my application only when uninstall, not updates and REP is after >> InstallInitialize) with component conditions. >> >> If I can't accomplish that with component conditions, I have to use some >> CustomActions like a batch file or so, which is never recommended >> because they can't be rolled-back. >> I kept reading all around on the forum stuff like: >> "But as Brian pointed out before, you should not use batch files. If >> you're writing registry values or copying files, use native authoring >> which is >> transacted. Batch files are not transactional in nature. You'd need a >> separate batch file scheduled before your deferred CA executed as a >> rollback CA. But what about when your product is repaired or patched? >> What then? Conditions become difficult. Keeping standard or even custom >> data dependent >> on component install and action states helps avoid most of these issues. " >> this is why I tried doing this with component conditions. >> >> That means there is no "approved" way of accomplishing this??? I >> wouldn't consider this being a so weird task: just deleting, when >> uninstalling, some files your app created and needs. I would have >> expected a standard way of doing this, and not through batch or other >> external custom actions as they can't be controlled during rollbacks. >> >> And still, why does this work when REP is after InstallFinalize? >> >> Thank you, >> MeCoco >> >> >> On 11/26/2010 1:57 PM, Michael Urman wrote: >>> Good job isolating it, but it's a problem understanding how component >>> conditions work. They only serve to gate when a component is >>> installed. With the transitive bit set, their going false can also >>> cause them to be uninstalled in a minor upgrade or other maintenance >>> scenario. However their being false will never prevent their >>> uninstallation. >>> >>> Because of this, the premise that a component condition can prevent >>> the RemoveFile table entry from executing during uninstall is flawed, >>> and you will need to find an alternate approach. Either it needs to be >>> tied to a component that is not removed, or possibly you will need to >>> use a custom action whose execution you can correctly condition (e.g. >>> something referring to the combination of component install and action >>> states as well as the presence of UPGRADINGPRODUCTCODE). >>> >>> On Fri, Nov 26, 2010 at 04:48, MeCoco<vcotirl...@hotmail.com> wrote: >>>> OK, this seems to be a MSI bug, because after investigating I noticed that: >>>> >>>> 1) by opening the created MSI with Orca I can see in the Component table: >>>> removeFile {F82061CB-27F9-41F5-B5FE-2EDCA1F1A8F9} >>>> INSTALLLOCATION 0 (REMOVE=ALL) AND (NOT UPGRADINGPRODUCTCODE) >>>> >>>> 2) The, after an update, in the log file I can see: >>>> >>>> Ln 448 >>>> MSI (s) (44:40) [11:03:35:733]: Command Line: >>>> UPGRADINGPRODUCTCODE={BD36EB78-4DDE-4567-A300-DC497B51F5F5} >>>> CLIENTUILEVEL=0 REMOVE=ALL >>>> >>>> Ln 717 >>>> MSI (s) (44:40) [11:03:36:184]: Executing op: >>>> FileRemove(,FileName=momo.txt,,) >>>> >>>> So, even thoug in the MSI the component is correctly written with it's >>>> condition and even though one can see in the log that >>>> UPGRADINGPRODUCTCODE is set, still later in the log one can see that >>>> the component is executed, so I would say this is a MSI problem. >>>> >>>> MeCoco >>>> >>>> On 11/26/2010 10:00 AM, MeCoco wrote: >>>>> Hi all, >>>>> >>>>> After searching any possible explanation on the internet, and after >>>>> trying any possible combination of conditions, I got to the conclusion >>>>> that this is either a bug or a limitation of Wix/MSI, because there is >>>>> no condition that could distinguish between an uninstall (from >>>>> add/remove programs) and an update, when REP is after InstallInitialize, >>>>> eg<RemoveExistingProducts After="InstallInitialize"/>. >>>>> >>>>> I'm not sure if I should report this somewhere or not, but I will post >>>>> again my sample here, as this sample proves this bug/limitation. >>>>> In order to distinguish between an uninstall (from control panel) and an >>>>> update, I used any possible combination of: >>>>> Installed, REMOVE="ALL", OLDAPPFOUND and UPGRADINGPRODUCTCODE without >>>>> success. >>>>> >>>>> I created a small sample file that shows exactly this problem, pls see >>>>> below. The problem can be easily duplicated by doing: >>>>> 1) build the below sample into a project with version 1.0.0 >>>>> 2) build the same sample but with another version 1.0.1 (change the >>>>> version in CurrentVersion) >>>>> 3) run version 1.0.0 => the product will be installed >>>>> 4) In C:\Program Files\MySmallProject add a dummy file: momo.txt (think >>>>> of it as a log file generated by running the application) >>>>> 5) run the second version 101, which _updates_ the product >>>>> >>>>> => after the update the momo.txt is !!gone!! even though the >>>>> component >>>>> which removes the file is having the condition: >>>>> (REMOVE=ALL) AND (NOT UPGRADINGPRODUCTCODE) >>>>> which means that the file shouldn't have been removed during an update >>>>> only during an uninstall. >>>>> >>>>> But if in the code instead of: >>>>> <RemoveExistingProducts After="InstallInitialize"/> >>>>> >>>>> you have: >>>>> <RemoveExistingProducts After="InstallFinalize"/> >>>>> >>>>> by doing all the above steps the momo.txt is _not_ deleted during an >>>>> update, only during a real uninstall (from add/remove programs), which >>>>> is the _desired_ behavior. >>>>> >>>>> So, it seems that when having<RemoveExistingProducts >>>>> After="InstallInitialize"/> there is no way to distinguish between an >>>>> uninstall and an update. >>>>> >>>>> The code that proves the above described behaviour: >>>>> >>>>> <?xml version="1.0" encoding="UTF-8"?> >>>>> >>>>> <?define UpgradeCode = "61608F07-C47C-459F-97DD-CD02D104294C"?> >>>>> <?define CurrentVersion = "1.0.0"?> >>>>> >>>>> <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi";> >>>>> <Product Id="*" Name="SmallProject" Language="1033" >>>>> Version="$(var.CurrentVersion)" Manufacturer="SmallProject" >>>>> UpgradeCode="$(var.UpgradeCode)"> >>>>> <Package Id="*" InstallerVersion="200" Compressed="yes" /> >>>>> >>>>> <Media Id="1" Cabinet="media1.cab" EmbedCab="yes" /> >>>>> >>>>> <Directory Id="TARGETDIR" Name="SourceDir"> >>>>> <Directory Id="ProgramFilesFolder"> >>>>> <Directory Id="INSTALLLOCATION" Name="MySmallProject"> >>>>> >>>>> <Component Id="mytest.txt" Guid="7CED77A9-597B-456A-BEF7-44C094800A06"> >>>>> <File Id="mytest.txt" Source="mytest.txt" KeyPath="yes" /> >>>>> </Component> >>>>> >>>>> <Component Id="removeFile" Guid="F82061CB-27F9-41F5-B5FE-2EDCA1F1A8F9"> >>>>> <RemoveFile Id="remove" Name="momo.txt" On="uninstall"/> >>>>> <Condition>(REMOVE=ALL) AND (NOT UPGRADINGPRODUCTCODE)</Condition> >>>>> </Component> >>>>> >>>>> </Directory> >>>>> </Directory> >>>>> </Directory> >>>>> >>>>> <Feature Id="ProductFeature" Title="SmallProject" Level="1"> >>>>> <ComponentRef Id="mytest.txt"/> >>>>> <ComponentRef Id="removeFile"/> >>>>> </Feature> >>>>> >>>>> <Upgrade Id="$(var.UpgradeCode)"> >>>>> <UpgradeVersion OnlyDetect="no" Property="OLDAPPFOUND" Minimum="0.0.1" >>>>> IncludeMinimum="yes" Maximum="$(var.CurrentVersion)" IncludeMaximum="no" >>>>> /> >>>>> <UpgradeVersion OnlyDetect="yes" Property="NEWAPPFOUND" >>>>> Minimum="$(var.CurrentVersion)" IncludeMinimum="no" /> >>>>> <UpgradeVersion OnlyDetect="yes" Property="SELFFOUND" >>>>> Minimum="$(var.CurrentVersion)" IncludeMinimum="yes" >>>>> Maximum="$(var.CurrentVersion)" IncludeMaximum="yes" /> >>>>> </Upgrade> >>>>> >>>>> <CustomAction Id="NewerVersionDetected" Error="2000"/> >>>>> <CustomAction Id="CurrentVersionDetected" Error="2001"/> >>>>> >>>>> <UI> <Error Id="2000">!(loc.Error2000)</Error> </UI> >>>>> <UI> <Error Id="2001">!(loc.Error2001)</Error> </UI> >>>>> >>>>> <InstallExecuteSequence> >>>>> <FindRelatedProducts Sequence="100" /> >>>>> <AppSearch After="FindRelatedProducts"/> >>>>> <LaunchConditions After="AppSearch" /> >>>>> <Custom Action="NewerVersionDetected" >>>>> After="AppSearch">NEWAPPFOUND</Custom> >>>>> <Custom Action="CurrentVersionDetected" >>>>> After="AppSearch">SELFFOUND</Custom> >>>>> <RemoveExistingProducts After="InstallInitialize"/> >>>>> <!--<RemoveExistingProducts After="InstallFinalize"/>--> >>>>> </InstallExecuteSequence> >>>>> >>>>> <!-- Find previous installation directory --> >>>>> <Property Id="INSTALLDIR"> >>>>> <RegistrySearch Id="FindInstallLocation" Root="HKLM" >>>>> Key="Software\Microsoft\Windows\CurrentVersion\Uninstall\[OLDAPPFOUND]" >>>>> Name="InstallLocation" Type="raw" /> >>>>> </Property> >>>>> >>>>> <CustomAction Id="SetARPINSTALLLOCATION" Property="ARPINSTALLLOCATION" >>>>> Value="[INSTALLDIR]" /> >>>>> <InstallExecuteSequence> >>>>> <Custom Action="SetARPINSTALLLOCATION" After="InstallValidate">NOT >>>>> Installed</Custom> >>>>> </InstallExecuteSequence> >>>>> >>>>> </Product> >>>>> </Wix> >>>>> >>>>> >>>>> Thank you, >>>>> MeCoco >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! >>>>> Tap into the largest installed PC base& get more eyes on your game by >>>>> optimizing for Intel(R) Graphics Technology. Get started today with the >>>>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >>>>> http://p.sf.net/sfu/intelisp-dev2dev >>>>> _______________________________________________ >>>>> WiX-users mailing list >>>>> WiX-users@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/wix-users >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! >>>> Tap into the largest installed PC base& get more eyes on your game by >>>> optimizing for Intel(R) Graphics Technology. Get started today with the >>>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >>>> http://p.sf.net/sfu/intelisp-dev2dev >>>> _______________________________________________ >>>> WiX-users mailing list >>>> WiX-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/wix-users >>>> >>> ------------------------------------------------------------------------------ >>> Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! >>> Tap into the largest installed PC base& get more eyes on your game by >>> optimizing for Intel(R) Graphics Technology. Get started today with the >>> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >>> http://p.sf.net/sfu/intelisp-dev2dev >>> _______________________________________________ >>> WiX-users mailing list >>> WiX-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> ------------------------------------------------------------------------------ >> Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! >> Tap into the largest installed PC base& get more eyes on your game by >> optimizing for Intel(R) Graphics Technology. Get started today with the >> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. >> http://p.sf.net/sfu/intelisp-dev2dev >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App& Earn a Chance To Win $500! > Tap into the largest installed PC base& get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
