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
