Absolutely; handling rollback scenarios can increase the complexity surrounding file removal several-fold.
(But when there aren't specific timing requirements, you just run such a delete from the commit phase.) Given that there is no clear way to know the future upgrade paths (does anyone ever pre-create a big batch of future ProductCode GUIDs?), it's a case where you're potentially doing the wrong thing down the line no matter what you choose to do now. On Tue, Nov 30, 2010 at 09:09, Rob Mensching <r...@robmensching.com> wrote: > Getting the RemoveFile table entry right is *a lot* easier than getting > rollback correct in all the cases it is required. The RemoveFoldersEx custom > action does the same sort of work in the > http://wix-contrib.codeplex.comproject. > > On Mon, Nov 29, 2010 at 7:02 AM, Michael Urman <mur...@gmail.com> 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 >> > > > > -- > virtually, Rob Mensching - http://RobMensching.com LLC > ------------------------------------------------------------------------------ > 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
