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
