Broken Link. The correct one is http://wixcontrib.codeplex.com/
-----Original Message----- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Tuesday, November 30, 2010 9:10 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] [BUG/limitation in WIX/MSI]No way to distinguish between an uninstall and an update when <RemoveExistingProducts After="InstallInitialize"/> 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
