Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one)

2011-03-10 Thread MeCoco
Thank you guys for all your help!

MeCoco

On 3/9/2011 4:19 PM, David Watson wrote:
 If you have a directory element with no @Name it just makes the @Id an alias
 of the containing element.

 So your code makes any files targeted to MyApp.Binaries go in the same
 location as INSTALLDIR.

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 09 March 2011 15:03
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has
 the default value, not the used one)

 Hi Michael,

 Thanks again for the explanation.

 Could you also tell me please what are the following lines of code
 actually do?:
 DirectoryRef Id=INSTALLDIR
 Directory Id=MyApp.Binaries /
 /DirectoryRef

 Thanks!
 MeCoco

 On 3/9/2011 3:08 PM, Michael Urman wrote:
 That doesn't look like it creates a component whose Directory is
 INSTALLDIR. It may put the component's file in the same directory, but
 since custom actions could override this, it doesn't count. What you
 need is the Directory_ column of the Component table to say INSTALLDIR
 instead of MyApp.Binaries, for at least one installed component.

 On Wed, Mar 9, 2011 at 02:29, MeCocovcotirl...@hotmail.com   wrote:
 Hi Michael,

 Thanks for your answer.

 Is the following code not enough to preserve the INSTALLDIR directory?

 Fragment
 DirectoryRef Id=INSTALLDIR
 Directory Id=MyApp.Binaries /
 /DirectoryRef
 /Fragment

 Fragment
 Component Id=MyApp.Binaries.app.config Directory=MyApp.Binaries
 Guid=MY-GUID
 File Id=MyApp.Binaries.app.config Source=MyApp.app.config /
 /Component
 /Fragment

 As the file MyApp.app.config ends up going into the INSTALLLOCATION
 directory?


 I am not even sure what the:
 Fragment
 DirectoryRef Id=INSTALLDIR
 Directory Id=MyApp.Binaries /
 /DirectoryRef
 /Fragment

 is doing as the:

 Directory Id=MyApp.Binaries /

 doesn't have any Name parameter, so it looks like redefining
 MyApp.Binaries to be the INSTALLDIR value. Am I assuming correct?


 Thanks,
 MeCoco

 On 3/8/2011 3:07 PM, Michael Urman wrote:
 Directories are only automatically preserved when there is a component
 that installs to it. So make sure at least one component installs to
 INSTALLDIR.

 On Tue, Mar 8, 2011 at 03:31, MeCocovcotirl...@hotmail.com wrote:
 Hi all,

 I tried to create a small sample to reproduce the problem I'm having,
 and after a lot of tries I managed to reproduce it. The problem is
 described extensivly in my previous email, but a summary would be: if
 the user, when installing, changes the default directory (eg: from
 C:\Program Files\... to Z:\Program Files\...), then on uninstall (only
 real uninstall, not updates) one can see in the verbose log file that
 the INSTALLDIR property is set wrong to the default value (eg:
 C:\Program Files\...) and not to the folder where the user really
 installed the product (eg: Z:\Program Files\...)

 HOW to reproduce the problem:

 1) If in the code I have the following:

 Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
 Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

 Component Id=MyDoc.txt Guid=6817A42D-30E7-464C-99DC-8FDBED6D70C6
 File Id=MyDoc.txt Source=MyDoc.txt KeyPath=yes Checksum=yes /
 /Component

 Directory Id=Modules Name=Modules

 Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
 File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes
 /
 /Component

 /Directory
 /Directory
 /Directory
 /Directory


 !-- application features --
 Feature Id=Application Title=$(var.ProductName) Application
 Level=1 Absent=disallow
 ComponentRef Id=MyLogo.txt /
 ComponentRef Id=MyDoc.txt /
 /Feature

 I get everything correct, meaning I have in the log file the following:
 MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding INSTALLDIR
 property. Its value is 'Z:\Program Files\MyTestInstallDirectory'.
 MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding Modules
 property. Its value is 'Z:\Program
 Files\MyTestInstallDirectory\Modules'.

 2) BUT, if in the code the MyDoc.txt component is missing, the
 INSTALLDIR property is wrong. So, for the code:

 Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
 Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

 Directory Id=Modules Name=Modules

 Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
 File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes
 /
 /Component

 /Directory
 /Directory
 /Directory
 /Directory


 !-- application features --
 Feature Id=Application Title=$(var.ProductName) Application
 Level=1 Absent=disallow
 ComponentRef Id=MyLogo.txt /
 /Feature

 In the log file I can see:
 MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Adding INSTALLDIR
 property. Its value is 'C:\Program Files\MyTestInstallDirectory\'.
 MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Modifying Modules
 property. Its current value is 'Z:\Program
 Files\MyTestInstallDirectory\Modules'. Its new

Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one)

2011-03-10 Thread MeCoco
And yes, just to be clear, once I added a component under the INSTALLDIR 
(not one of it's alias) the INSTALLDIR was also correctly preserved for 
uninstall.

Thx,
MeCoco

On 3/10/2011 10:39 AM, MeCoco wrote:
 Thank you guys for all your help!

 MeCoco

 On 3/9/2011 4:19 PM, David Watson wrote:
 If you have a directory element with no @Name it just makes the @Id an alias
 of the containing element.

 So your code makes any files targeted to MyApp.Binaries go in the same
 location as INSTALLDIR.

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 09 March 2011 15:03
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has
 the default value, not the used one)

 Hi Michael,

 Thanks again for the explanation.

 Could you also tell me please what are the following lines of code
 actually do?:
 DirectoryRef Id=INSTALLDIR
 Directory Id=MyApp.Binaries /
 /DirectoryRef

 Thanks!
 MeCoco

 On 3/9/2011 3:08 PM, Michael Urman wrote:
 That doesn't look like it creates a component whose Directory is
 INSTALLDIR. It may put the component's file in the same directory, but
 since custom actions could override this, it doesn't count. What you
 need is the Directory_ column of the Component table to say INSTALLDIR
 instead of MyApp.Binaries, for at least one installed component.

 On Wed, Mar 9, 2011 at 02:29, MeCocovcotirl...@hotmail.comwrote:
 Hi Michael,

 Thanks for your answer.

 Is the following code not enough to preserve the INSTALLDIR directory?

 Fragment
 DirectoryRef Id=INSTALLDIR
 Directory Id=MyApp.Binaries /
 /DirectoryRef
 /Fragment

 Fragment
 Component Id=MyApp.Binaries.app.config Directory=MyApp.Binaries
 Guid=MY-GUID
 File Id=MyApp.Binaries.app.config Source=MyApp.app.config /
 /Component
 /Fragment

 As the file MyApp.app.config ends up going into the INSTALLLOCATION
 directory?


 I am not even sure what the:
 Fragment
 DirectoryRef Id=INSTALLDIR
 Directory Id=MyApp.Binaries /
 /DirectoryRef
 /Fragment

 is doing as the:

 Directory Id=MyApp.Binaries /

 doesn't have any Name parameter, so it looks like redefining
 MyApp.Binaries to be the INSTALLDIR value. Am I assuming correct?


 Thanks,
 MeCoco

 On 3/8/2011 3:07 PM, Michael Urman wrote:
 Directories are only automatically preserved when there is a component
 that installs to it. So make sure at least one component installs to
 INSTALLDIR.

 On Tue, Mar 8, 2011 at 03:31, MeCocovcotirl...@hotmail.com  wrote:
 Hi all,

 I tried to create a small sample to reproduce the problem I'm having,
 and after a lot of tries I managed to reproduce it. The problem is
 described extensivly in my previous email, but a summary would be: if
 the user, when installing, changes the default directory (eg: from
 C:\Program Files\... to Z:\Program Files\...), then on uninstall (only
 real uninstall, not updates) one can see in the verbose log file that
 the INSTALLDIR property is set wrong to the default value (eg:
 C:\Program Files\...) and not to the folder where the user really
 installed the product (eg: Z:\Program Files\...)

 HOW to reproduce the problem:

 1) If in the code I have the following:

 Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
 Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

 Component Id=MyDoc.txt Guid=6817A42D-30E7-464C-99DC-8FDBED6D70C6
 File Id=MyDoc.txt Source=MyDoc.txt KeyPath=yes Checksum=yes /
 /Component

 Directory Id=Modules Name=Modules

 Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
 File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes
 /
 /Component

 /Directory
 /Directory
 /Directory
 /Directory


 !-- application features --
 Feature Id=Application Title=$(var.ProductName) Application
 Level=1 Absent=disallow
 ComponentRef Id=MyLogo.txt /
 ComponentRef Id=MyDoc.txt /
 /Feature

 I get everything correct, meaning I have in the log file the following:
 MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding INSTALLDIR
 property. Its value is 'Z:\Program Files\MyTestInstallDirectory'.
 MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding Modules
 property. Its value is 'Z:\Program
 Files\MyTestInstallDirectory\Modules'.
 2) BUT, if in the code the MyDoc.txt component is missing, the
 INSTALLDIR property is wrong. So, for the code:

 Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
 Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

 Directory Id=Modules Name=Modules

 Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
 File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes
 /
 /Component

 /Directory
 /Directory
 /Directory
 /Directory


 !-- application features --
 Feature Id=Application Title=$(var.ProductName) Application
 Level=1 Absent=disallow
 ComponentRef Id=MyLogo.txt /
 /Feature

 In the log file I can see:
 MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Adding INSTALLDIR
 property. Its

Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one)

2011-03-09 Thread MeCoco
Hi Michael,

Thanks for your answer.

Is the following code not enough to preserve the INSTALLDIR directory?

Fragment
DirectoryRef Id=INSTALLDIR
Directory Id=MyApp.Binaries /
/DirectoryRef
/Fragment

Fragment
Component Id=MyApp.Binaries.app.config Directory=MyApp.Binaries 
Guid=MY-GUID
File Id=MyApp.Binaries.app.config Source=MyApp.app.config /
/Component
/Fragment

As the file MyApp.app.config ends up going into the INSTALLLOCATION 
directory?


I am not even sure what the:
Fragment
DirectoryRef Id=INSTALLDIR
Directory Id=MyApp.Binaries /
/DirectoryRef
/Fragment

is doing as the:

Directory Id=MyApp.Binaries /

doesn't have any Name parameter, so it looks like redefining 
MyApp.Binaries to be the INSTALLDIR value. Am I assuming correct?


Thanks,
MeCoco

On 3/8/2011 3:07 PM, Michael Urman wrote:
 Directories are only automatically preserved when there is a component
 that installs to it. So make sure at least one component installs to
 INSTALLDIR.

 On Tue, Mar 8, 2011 at 03:31, MeCocovcotirl...@hotmail.com  wrote:
 Hi all,

 I tried to create a small sample to reproduce the problem I'm having,
 and after a lot of tries I managed to reproduce it. The problem is
 described extensivly in my previous email, but a summary would be: if
 the user, when installing, changes the default directory (eg: from
 C:\Program Files\... to Z:\Program Files\...), then on uninstall (only
 real uninstall, not updates) one can see in the verbose log file that
 the INSTALLDIR property is set wrong to the default value (eg:
 C:\Program Files\...) and not to the folder where the user really
 installed the product (eg: Z:\Program Files\...)

 HOW to reproduce the problem:

 1) If in the code I have the following:

 Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
 Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

 Component Id=MyDoc.txt Guid=6817A42D-30E7-464C-99DC-8FDBED6D70C6
 File Id=MyDoc.txt Source=MyDoc.txt KeyPath=yes Checksum=yes /
 /Component

 Directory Id=Modules Name=Modules

 Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
 File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes /
 /Component

 /Directory
 /Directory
 /Directory
 /Directory


 !-- application features --
 Feature Id=Application Title=$(var.ProductName) Application
 Level=1 Absent=disallow
 ComponentRef Id=MyLogo.txt /
 ComponentRef Id=MyDoc.txt /
 /Feature

 I get everything correct, meaning I have in the log file the following:
 MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding INSTALLDIR
 property. Its value is 'Z:\Program Files\MyTestInstallDirectory'.
 MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding Modules
 property. Its value is 'Z:\Program Files\MyTestInstallDirectory\Modules'.


 2) BUT, if in the code the MyDoc.txt component is missing, the
 INSTALLDIR property is wrong. So, for the code:

 Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
 Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

 Directory Id=Modules Name=Modules

 Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
 File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes /
 /Component

 /Directory
 /Directory
 /Directory
 /Directory


 !-- application features --
 Feature Id=Application Title=$(var.ProductName) Application
 Level=1 Absent=disallow
 ComponentRef Id=MyLogo.txt /
 /Feature

 In the log file I can see:
 MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Adding INSTALLDIR
 property. Its value is 'C:\Program Files\MyTestInstallDirectory\'.
 MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Modifying Modules
 property. Its current value is 'Z:\Program
 Files\MyTestInstallDirectory\Modules'. Its new value: 'Z:\Program
 Files\MyTestInstallDirectory\Modules\'.


 Is this a bug or am I doing something wrong? I think in both cases the
 INSTALLDIR should have the correct value (Z:\Program Files\...) on
 uninstall.
 Any tip is appreciated.
 Thank you,
 MeCoco



 On 3/7/2011 7:24 PM, MeCoco wrote:
 Hi all,

 I have a very extensive installer, written by somebody that left our
 company, and I have to add a custom action that should be executed at
 the end of the uninstaller (only when completely removed from control
 panel, not in case of an update) in order to remove a file that was at
 a later point created by our product.

 I wrote a small test-installer to do just that and everything works
 fine: the custom action that  should delete a specific file from the
 installation directory is run at the end of the uninstallation:

 CustomAction Id=QtExecDeferred_Cmd1 Property=QtExecDeferred1
 Value='[SystemFolder]Cmd.exe  /C del /Q [INSTALLLOCATION
 ]MyLogo.txt'/
 CustomAction Id=QtExecDeferred1 BinaryKey=WixCA
 DllEntry=CAQuietExec Execute=deferred Return=ignore
 Impersonate=no/

 InstallExecuteSequence
 Custom Action=QtExecDeferred_Cmd1
 Before=QtExecDeferred1REMOVE=ALL AND NOT
 UPGRADINGPRODUCTCODE/Custom
 Custom Action=QtExecDeferred1
 After

Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one)

2011-03-09 Thread MeCoco
Hi Michael,

Thanks again for the explanation.

Could you also tell me please what are the following lines of code 
actually do?:
DirectoryRef Id=INSTALLDIR
Directory Id=MyApp.Binaries /
/DirectoryRef

Thanks!
MeCoco

On 3/9/2011 3:08 PM, Michael Urman wrote:
 That doesn't look like it creates a component whose Directory is
 INSTALLDIR. It may put the component's file in the same directory, but
 since custom actions could override this, it doesn't count. What you
 need is the Directory_ column of the Component table to say INSTALLDIR
 instead of MyApp.Binaries, for at least one installed component.

 On Wed, Mar 9, 2011 at 02:29, MeCocovcotirl...@hotmail.com  wrote:
 Hi Michael,

 Thanks for your answer.

 Is the following code not enough to preserve the INSTALLDIR directory?

 Fragment
 DirectoryRef Id=INSTALLDIR
 Directory Id=MyApp.Binaries /
 /DirectoryRef
 /Fragment

 Fragment
 Component Id=MyApp.Binaries.app.config Directory=MyApp.Binaries
 Guid=MY-GUID
 File Id=MyApp.Binaries.app.config Source=MyApp.app.config /
 /Component
 /Fragment

 As the file MyApp.app.config ends up going into the INSTALLLOCATION
 directory?


 I am not even sure what the:
 Fragment
 DirectoryRef Id=INSTALLDIR
 Directory Id=MyApp.Binaries /
 /DirectoryRef
 /Fragment

 is doing as the:

 Directory Id=MyApp.Binaries /

 doesn't have any Name parameter, so it looks like redefining
 MyApp.Binaries to be the INSTALLDIR value. Am I assuming correct?


 Thanks,
 MeCoco

 On 3/8/2011 3:07 PM, Michael Urman wrote:
 Directories are only automatically preserved when there is a component
 that installs to it. So make sure at least one component installs to
 INSTALLDIR.

 On Tue, Mar 8, 2011 at 03:31, MeCocovcotirl...@hotmail.comwrote:
 Hi all,

 I tried to create a small sample to reproduce the problem I'm having,
 and after a lot of tries I managed to reproduce it. The problem is
 described extensivly in my previous email, but a summary would be: if
 the user, when installing, changes the default directory (eg: from
 C:\Program Files\... to Z:\Program Files\...), then on uninstall (only
 real uninstall, not updates) one can see in the verbose log file that
 the INSTALLDIR property is set wrong to the default value (eg:
 C:\Program Files\...) and not to the folder where the user really
 installed the product (eg: Z:\Program Files\...)

 HOW to reproduce the problem:

 1) If in the code I have the following:

 Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
 Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

 Component Id=MyDoc.txt Guid=6817A42D-30E7-464C-99DC-8FDBED6D70C6
 File Id=MyDoc.txt Source=MyDoc.txt KeyPath=yes Checksum=yes /
 /Component

 Directory Id=Modules Name=Modules

 Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
 File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes /
 /Component

 /Directory
 /Directory
 /Directory
 /Directory


 !-- application features --
 Feature Id=Application Title=$(var.ProductName) Application
 Level=1 Absent=disallow
 ComponentRef Id=MyLogo.txt /
 ComponentRef Id=MyDoc.txt /
 /Feature

 I get everything correct, meaning I have in the log file the following:
 MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding INSTALLDIR
 property. Its value is 'Z:\Program Files\MyTestInstallDirectory'.
 MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding Modules
 property. Its value is 'Z:\Program Files\MyTestInstallDirectory\Modules'.


 2) BUT, if in the code the MyDoc.txt component is missing, the
 INSTALLDIR property is wrong. So, for the code:

 Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
 Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

 Directory Id=Modules Name=Modules

 Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
 File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes /
 /Component

 /Directory
 /Directory
 /Directory
 /Directory


 !-- application features --
 Feature Id=Application Title=$(var.ProductName) Application
 Level=1 Absent=disallow
 ComponentRef Id=MyLogo.txt /
 /Feature

 In the log file I can see:
 MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Adding INSTALLDIR
 property. Its value is 'C:\Program Files\MyTestInstallDirectory\'.
 MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Modifying Modules
 property. Its current value is 'Z:\Program
 Files\MyTestInstallDirectory\Modules'. Its new value: 'Z:\Program
 Files\MyTestInstallDirectory\Modules\'.


 Is this a bug or am I doing something wrong? I think in both cases the
 INSTALLDIR should have the correct value (Z:\Program Files\...) on
 uninstall.
 Any tip is appreciated.
 Thank you,
 MeCoco



 On 3/7/2011 7:24 PM, MeCoco wrote:
 Hi all,

 I have a very extensive installer, written by somebody that left our
 company, and I have to add a custom action that should be executed at
 the end of the uninstaller (only when completely removed from control
 panel, not in case of an update) in order to remove a file

Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one)

2011-03-08 Thread MeCoco
Hi all,

I tried to create a small sample to reproduce the problem I'm having, 
and after a lot of tries I managed to reproduce it. The problem is 
described extensivly in my previous email, but a summary would be: if 
the user, when installing, changes the default directory (eg: from 
C:\Program Files\... to Z:\Program Files\...), then on uninstall (only 
real uninstall, not updates) one can see in the verbose log file that 
the INSTALLDIR property is set wrong to the default value (eg: 
C:\Program Files\...) and not to the folder where the user really 
installed the product (eg: Z:\Program Files\...)

HOW to reproduce the problem:

1) If in the code I have the following:

Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

Component Id=MyDoc.txt Guid=6817A42D-30E7-464C-99DC-8FDBED6D70C6
File Id=MyDoc.txt Source=MyDoc.txt KeyPath=yes Checksum=yes /
/Component

Directory Id=Modules Name=Modules

Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes /
/Component

/Directory
/Directory
/Directory
/Directory


!-- application features --
Feature Id=Application Title=$(var.ProductName) Application 
Level=1 Absent=disallow
ComponentRef Id=MyLogo.txt /
ComponentRef Id=MyDoc.txt /
/Feature

I get everything correct, meaning I have in the log file the following:
MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding INSTALLDIR 
property. Its value is 'Z:\Program Files\MyTestInstallDirectory'.
MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding Modules 
property. Its value is 'Z:\Program Files\MyTestInstallDirectory\Modules'.


2) BUT, if in the code the MyDoc.txt component is missing, the 
INSTALLDIR property is wrong. So, for the code:

Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

Directory Id=Modules Name=Modules

Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB
File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes /
/Component

/Directory
/Directory
/Directory
/Directory


!-- application features --
Feature Id=Application Title=$(var.ProductName) Application 
Level=1 Absent=disallow
ComponentRef Id=MyLogo.txt /
/Feature

In the log file I can see:
MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Adding INSTALLDIR 
property. Its value is 'C:\Program Files\MyTestInstallDirectory\'.
MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Modifying Modules 
property. Its current value is 'Z:\Program 
Files\MyTestInstallDirectory\Modules'. Its new value: 'Z:\Program 
Files\MyTestInstallDirectory\Modules\'.


Is this a bug or am I doing something wrong? I think in both cases the 
INSTALLDIR should have the correct value (Z:\Program Files\...) on 
uninstall.
Any tip is appreciated.
Thank you,
MeCoco



On 3/7/2011 7:24 PM, MeCoco wrote:
 Hi all,

 I have a very extensive installer, written by somebody that left our 
 company, and I have to add a custom action that should be executed at 
 the end of the uninstaller (only when completely removed from control 
 panel, not in case of an update) in order to remove a file that was at 
 a later point created by our product.

 I wrote a small test-installer to do just that and everything works 
 fine: the custom action that  should delete a specific file from the 
 installation directory is run at the end of the uninstallation:

 CustomAction Id=QtExecDeferred_Cmd1 Property=QtExecDeferred1 
 Value='[SystemFolder]Cmd.exe  /C del /Q [INSTALLLOCATION 
 ]MyLogo.txt'/
 CustomAction Id=QtExecDeferred1 BinaryKey=WixCA 
 DllEntry=CAQuietExec Execute=deferred Return=ignore 
 Impersonate=no/

 InstallExecuteSequence
 Custom Action=QtExecDeferred_Cmd1 
 Before=QtExecDeferred1REMOVE=ALL AND NOT 
 UPGRADINGPRODUCTCODE/Custom
 Custom Action=QtExecDeferred1 
 After=RemoveExistingProductsREMOVE=ALL AND NOT 
 UPGRADINGPRODUCTCODE/Custom
 /InstallExecuteSequence



 The problem is that when I try to integrate the exact same code into 
 the big installer this doesn't work anymore. The installer is a 
 WIXUI_INSTALLDIR.
 I generated a verbose log file and I noticed that the INSTALLLOCATION 
 property is wrong when uninstalling the product, instead of being the 
 real directory where the product was installed (chosen by the user, 
 eg: Z:\momo) is actually the default directory (eg: C:\Program 
 Files\MyApp), so the file that needs to be deleted: 
 [INSTALLLOCATION]MyLogo.txt is not found because the INSTALLLOCATION 
 is not correct. Weird is, that only in the uninstall case, the 
 INSTALLLOCATION property is wrong. In case of an update it looks ok 
 (eg Z:\momo). As one can see in the attached log file, some paths 
 there are the correct ones: Z:\Program Files\... and some are the 
 wrong ones: C:\Program Files\...

 As the INSTALLLOCATION is correct in my small test-installer during 
 uninstall, it is smth in this big and extensive installer

Re: [WiX-users] WiX source code download

2011-01-17 Thread MeCoco
OK, the sources, for different versions, can be downloaded here:
http://wix.sourceforge.net/releases/

The link can be found when going to: http://wix.sourceforge.net/ and 
clicking Weekly Releases.

MeCoco

On 1/14/2011 5:25 PM, MeCoco wrote:
 Hi all,

 I want to get the WiX sources but on sourceforge I found that they were
 moved:
 WiX toolset source and releases move to CodePlex.
 June 6th, 2010
 The WiX toolset source code and file releases have moved off of
 SourceForge to CodePlex

 I went to the:
 http://wix.codeplex.com/

 but here I can't seem to find how can I download the WiX _source code_
 for V 3.0. Can smbd give me a link?

 Thank you.
 MeCoco

 --
 Protect Your Site and Customers from Malware Attacks
 Learn about various malware tactics and how to avoid them. Understand
 malware threats, the impact they can have on your business, and how you
 can protect your company and customers by using code signing.
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] WiX source code download

2011-01-14 Thread MeCoco
Hi all,

I want to get the WiX sources but on sourceforge I found that they were 
moved:
WiX toolset source and releases move to CodePlex.
June 6th, 2010
The WiX toolset source code and file releases have moved off of 
SourceForge to CodePlex

I went to the:
http://wix.codeplex.com/

but here I can't seem to find how can I download the WiX _source code_ 
for V 3.0. Can smbd give me a link?

Thank you.
MeCoco

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Delete the shortcuts on uninstall

2011-01-11 Thread MeCoco
OK, I found the problem: I copy/pasted the code into a new sample and 
forgot to change the GUID :( Once I use a unique GUID everything works fine.

MeCoco

On 1/10/2011 6:02 PM, MeCoco wrote:
 Hi all,

 I wrote the needed code to create 2 shortcuts: one in the Start Menu and
 the other one on the desktop. The problem is that when uninstalling the
 product the shortcuts are not deleted, they both remain in the system.

 The code looks like:
 Directory Id=TARGETDIR Name=SourceDir
 Directory Id=ProgramFilesFolder
 Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

 Component Id=MyDoc.txt Guid=MY-GUID
 File Id=MyDoc.txt Source=MyDoc.txt KeyPath=yes Checksum=yes /
 /Component

 /Directory
 /Directory

 Directory Id=ProgramMenuFolder
 Directory Id=ApplicationProgramsFolder Name=$(var.ProductName)/
 /Directory
 Directory Id=PersonalFolder
 Directory Id=UserLocalAppData Name=MyAgent /
 /Directory
 Directory Id=DesktopFolder /

 /Directory

 !-- Program Shortcut --
 Component Id=ApplicationShortcut Guid={MY-GUID}
 Directory=ApplicationProgramsFolder
 !-- Start menu shortcut --
 Shortcut Id=ApplicationStartMenuShortcut
   Name=$(var.ProductName)
   Description=$(var.ProductName) Application
   Target=[INSTALLDIR]MyDoc.txt
   WorkingDirectory=INSTALLDIR/
 !-- Desktop shortcut --
 Shortcut Id=DesktopShortcut
   Name=$(var.ProductName)
   Description=$(var.ProductName) Application
   Directory=DesktopFolder
   Target=[INSTALLDIR]MyDoc.txt
   WorkingDirectory=INSTALLDIR/
 CreateFolder Directory=UserLocalAppData /
 RemoveFolder Id=ApplicationProgramsFolder On=uninstall/
 RemoveFolder Id=UserLocalAppData Directory=UserLocalAppData
 On=uninstall/
 RegistryValue Root=HKCU Key=Software\Microsoft\Installer
 Name=$(var.ProductName) Type=integer Value=1 KeyPath=yes/
 /Component

 !--Install per machine--
 Property Id=ALLUSERS Value=1 /

 !--Application features--
 Feature Id=MainApp Level=1 Title=$(var.ProductName)
 Absent=disallow ConfigurableDirectory=INSTALLDIR
 ComponentRef Id=MyDoc.txt /
 ComponentRef Id=ApplicationShortcut/
 /Feature


 Can pls somebody point me where am I doing smth wrong? The shortcuts are
 never deleted, neither when uninstalling the program from add/remove
 programs, nor when uninstalling it via an upgrade.
 Thank you!
 MeCoco

 --
 Gaining the trust of online customers is vital for the success of any company
 that requires sensitive data to be transmitted over the Web.   Learn how to
 best implement a security strategy that keeps consumers' information secure
 and instills the confidence they need to proceed with transactions.
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Let the user choose the installation directory onlyon first install, and not on updates

2011-01-10 Thread MeCoco
Hi Pally,

Thanks a lot for your answers. Actually in a major upgrade the last used 
directory used for installation is shown in the dialog, but the user 
could still _change_ it, so I think I'll have to go with your first 
answer. I will investigate on how to do it.

Thank you,
MeCoco

On 1/10/2011 2:59 PM, Pally Sandher wrote:
 Actually having just run a couple of major upgrades, my advice is to do
 nothing. It works as per your requirements without any changes.

 Palbinder Sandher
 Software Deployment  IT Administrator
 T: +44 (0) 141 945 8500
 F: +44 (0) 141 945 8501

 http://www.iesve.com
 **Design, Simulate + Innovate with theVirtual Environment**
 Integrated Environmental Solutions Limited. Registered in Scotland No.
 SC151456
 Registered Office - Helix Building, West Of Scotland Science Park,
 Glasgow G20 0SP
 Email Disclaimer

 -Original Message-
 From: Pally Sandher [mailto:pally.sand...@iesve.com]
 Sent: 10 January 2011 13:07
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Let the user choose the installation directory
 onlyon first install, and not on updates

 I assume by update you mean major upgrades?
 You could simply Condition the calls to InstallDirDlg from
 LicenseAgreementDlg  VerifyReadyDlg appropriately so it only shows
 during first install.

 Palbinder Sandher
 Software Deployment  IT Administrator
 T: +44 (0) 141 945 8500
 F: +44 (0) 141 945 8501

 http://www.iesve.com
 **Design, Simulate + Innovate with theVirtual Environment**
 Integrated Environmental Solutions Limited. Registered in Scotland No.
 SC151456
 Registered Office - Helix Building, West Of Scotland Science Park,
 Glasgow G20 0SP Email Disclaimer

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 07 January 2011 15:51
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] Let the user choose the installation directory only
 on first install, and not on updates

 Hi all,

 I have the requirement to change the installer to do the following:
 - on first install to give the user the chance to choose the
 installation directory
 - on updates _not_ to give the user the option to chose the installation
 directory (the directory used for the previous installation will be used
 for updates by default)

 I'm using right now:
 Property Id=WIXUI_INSTALLDIR Value=INSTALLDIR /  UIRef
 Id=WixUI_InstallDir /  UIRef Id=WixUI_ErrorProgressText /

 I assume, theoretically, I could do one of the following:
 - either somehow disable the Change button on the Installation
 directory Dialog, in case of updates
 - or to show on first installation the WixUI_InstallDir and on updates
 the WixUI_Minimal

 But I don't know how to implement any of above. Can somebody give me
 some ideas?

 Thanks!
 MeCoco

 
 --
 Gaining the trust of online customers is vital for the success of any
 company
 that requires sensitive data to be transmitted over the Web.   Learn how
 to
 best implement a security strategy that keeps consumers' information
 secure and instills the confidence they need to proceed with
 transactions.
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



 
 --
 Gaining the trust of online customers is vital for the success of any
 company
 that requires sensitive data to be transmitted over the Web.   Learn how
 to
 best implement a security strategy that keeps consumers' information
 secure
 and instills the confidence they need to proceed with transactions.
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



 --
 Gaining the trust of online customers is vital for the success of any company
 that requires sensitive data to be transmitted over the Web.   Learn how to
 best implement a security strategy that keeps consumers' information secure
 and instills the confidence they need to proceed with transactions.
 http://p.sf.net/sfu/oracle-sfdevnl
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl

[WiX-users] Delete the shortcuts on uninstall

2011-01-10 Thread MeCoco
Hi all,

I wrote the needed code to create 2 shortcuts: one in the Start Menu and 
the other one on the desktop. The problem is that when uninstalling the 
product the shortcuts are not deleted, they both remain in the system.

The code looks like:
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName)

Component Id=MyDoc.txt Guid=MY-GUID
File Id=MyDoc.txt Source=MyDoc.txt KeyPath=yes Checksum=yes /
/Component

/Directory
/Directory

Directory Id=ProgramMenuFolder
Directory Id=ApplicationProgramsFolder Name=$(var.ProductName)/
/Directory
Directory Id=PersonalFolder
Directory Id=UserLocalAppData Name=MyAgent /
/Directory
Directory Id=DesktopFolder /

/Directory

!-- Program Shortcut --
Component Id=ApplicationShortcut Guid={MY-GUID} 
Directory=ApplicationProgramsFolder
!-- Start menu shortcut --
Shortcut Id=ApplicationStartMenuShortcut
 Name=$(var.ProductName)
 Description=$(var.ProductName) Application
 Target=[INSTALLDIR]MyDoc.txt
 WorkingDirectory=INSTALLDIR/
!-- Desktop shortcut --
Shortcut Id=DesktopShortcut
 Name=$(var.ProductName)
 Description=$(var.ProductName) Application
 Directory=DesktopFolder
 Target=[INSTALLDIR]MyDoc.txt
 WorkingDirectory=INSTALLDIR/
CreateFolder Directory=UserLocalAppData /
RemoveFolder Id=ApplicationProgramsFolder On=uninstall/
RemoveFolder Id=UserLocalAppData Directory=UserLocalAppData 
On=uninstall/
RegistryValue Root=HKCU Key=Software\Microsoft\Installer 
Name=$(var.ProductName) Type=integer Value=1 KeyPath=yes/
/Component

!--Install per machine--
Property Id=ALLUSERS Value=1 /

!--Application features--
Feature Id=MainApp Level=1 Title=$(var.ProductName) 
Absent=disallow ConfigurableDirectory=INSTALLDIR
ComponentRef Id=MyDoc.txt /
ComponentRef Id=ApplicationShortcut/
/Feature


Can pls somebody point me where am I doing smth wrong? The shortcuts are 
never deleted, neither when uninstalling the program from add/remove 
programs, nor when uninstalling it via an upgrade.
Thank you!
MeCoco

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Let the user choose the installation directory only on first install, and not on updates

2011-01-07 Thread MeCoco
Hi all,

I have the requirement to change the installer to do the following:
- on first install to give the user the chance to choose the 
installation directory
- on updates _not_ to give the user the option to chose the installation 
directory (the directory used for the previous installation will be used 
for updates by default)

I'm using right now:
Property Id=WIXUI_INSTALLDIR Value=INSTALLDIR /
UIRef Id=WixUI_InstallDir /
UIRef Id=WixUI_ErrorProgressText /

I assume, theoretically, I could do one of the following:
- either somehow disable the Change button on the Installation 
directory Dialog, in case of updates
- or to show on first installation the WixUI_InstallDir and on updates 
the WixUI_Minimal

But I don't know how to implement any of above. Can somebody give me 
some ideas?

Thanks!
MeCoco

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] [BUG/limitation in WIX/MSI]No way to distinguish between an uninstall and an update when RemoveExistingProducts After=InstallInitialize/

2010-11-30 Thread MeCoco
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=RemoveExistingProductsREMOVE=ALL AND NOT 
UPGRADINGPRODUCTCODE/Custom
Custom Action=QtExecDeferred_Cmd Before=QtExecDeferredREMOVE=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, MeCocovcotirl...@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, MeCocovcotirl...@hotmail.comwrote:
 OK, this seems to be a MSI bug, because after investigating I noticed that:

 1

Re: [WiX-users] QtExecDeferred and using a property in the cmd line

2010-11-30 Thread MeCoco
Hi Peter,

Thanks for the link. I'll have a look.

MeCoco

On 11/29/2010 4:04 PM, Peter Shirtcliffe wrote:
 I see why you need a custom action. Your best approach is to have your
 custom action write temporary rows to the RemoveFile table and let
 Windows Installer do the deleting for you. That would prevent some
 potential problems.

 The pattern for these types of CAs is described in Bob's well-thumbed
 blog page at http://www.joyofsetup.com/2007/07/01/semi-custom-actions/

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 29 November 2010 14:25
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] QtExecDeferred and using a property in the cmd
 line

 Hi Peter.

 Thx for your answer, but I can't do that because I need the files to be
 removed _only_ when uninstall (not updates) and I have
 RemoveExistingProducts After=InstallInitialize/. And as I described
 here:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/BUG-limita
 tion-in-WIX-MSI-No-way-to-distinguish-between-an-uninstall-and-an-update
 -when-lt-RemoveExi-td5776494.html
 when REP is after InstallInitialize, it can't be done with Component
 conditions.

 So I need a CustomAction which deletes the file and can be conditioned
 to happen only when real uninstalls. Because of that I got to the code
 below, which doesn't work.
 Can somebody pls help me?

 Thanks,
 MeCoco

 On 11/29/2010 2:54 PM, Peter Shirtcliffe wrote:
 Use theRemoveFile   element instead.


 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 29 November 2010 13:45
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] QtExecDeferred and using a property in the cmd
 line
 Hi all,

 I need to delete a specific file (created by our product) after
 uninstalling the product. For that I'm using the Quiet Execution
 CustomAction like:

 Property Id=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/
 /InstallExecuteSequence


 When I'm building this I get the following 2 warnings:

 warning CNDL1077: The 'QtExecDeferred' Property contains
 '[SystemFolder]' in its value which is an illegal reference to another
 property.  If this value is a string literal, not a property
 reference,
 please ignore this warning.  To set a property with the value of
 another
 property, use a CustomAction with Property and Value attributes.
 warning CNDL1077: The 'QtExecDeferred' Property contains
 '[APPLICATIONFOLDER]' in its value which is an illegal reference to
 another property.  If this value is a string literal, not a property
 reference, please ignore this warning.  To set a property with the
 value
 of another property, use a CustomAction with Property and Value
 attributes.

 By looking into the log file, I see that the execution failed, with
 file not found:
 MSI (s) (4C:28) [14:26:46:842]: Executing op:

 CustomActionSchedule(Action=QtExecDeferred,ActionType=3137,Source=Binary
 Data,Target=CAQuietExec,CustomActionData=[SystemFolder]\Cmd.exe
 /C del /Q [INSTALLLOCATION]\momo.txt)
 MSI (s) (4C:80) [14:26:46:853]: Invoking remote custom action. DLL:
 C:\Windows\Installer\MSI8DF2.tmp, Entrypoint: CAQuietExec
 MSI (s) (4C:80) [14:26:46:853]: Generating random cookie.
 MSI (s) (4C:80) [14:26:46:871]: Created Custom Action Server with PID
 7996 (0x1F3C).
 MSI (s) (4C:4C) [14:26:46:973]: Running as a service.
 MSI (s) (4C:4C) [14:26:46:976]: Hello, I'm your 32bit Elevated custom
 action server.
 CAQuietExec:  Error 0x80070002: Command failed to execute.
 CAQuietExec:  Error 0x80070002: CAQuietExec Failed


 I assume the problem is that I'm using [SystemFolder] and
 [INSTALLLOCATION] in a deferred CustomAction.

 By searching the internet I found somebody saying:
You can't access properties directly from a defered custom action.
 You
   have to use another custom action that sets a property matching
 the
 name of
   your action.

 The problem is that I don't know how to do that? Can someone pls,
 taking
 in account the above lines of code, tell me how and what do I need to
 change to follow this instruction?

 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
 SDL PLC confidential, all rights

Re: [WiX-users] QtExecDeferred and using a property in the cmd line

2010-11-30 Thread MeCoco
Hi Sean,

Would be great if you would post the code here. There are so many 
unanswered posts about this issue that you most probably will make a lot 
of people happy.

Thank you,
MeCoco

On 11/29/2010 4:43 PM, Sean Farrow wrote:
 Hi:
 That's what I'm in the process of doing for a very similar situation.
 I'll post code when finished, should be a couple of days.
 Cheers
 Sean.
 -Original Message-
 From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
 Sent: 29 November 2010 15:05
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] QtExecDeferred and using a property in the cmd line

 I see why you need a custom action. Your best approach is to have your
 custom action write temporary rows to the RemoveFile table and let
 Windows Installer do the deleting for you. That would prevent some
 potential problems.

 The pattern for these types of CAs is described in Bob's well-thumbed
 blog page at http://www.joyofsetup.com/2007/07/01/semi-custom-actions/

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 29 November 2010 14:25
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] QtExecDeferred and using a property in the cmd
 line

 Hi Peter.

 Thx for your answer, but I can't do that because I need the files to be
 removed _only_ when uninstall (not updates) and I have
 RemoveExistingProducts After=InstallInitialize/. And as I described
 here:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/BUG-limita
 tion-in-WIX-MSI-No-way-to-distinguish-between-an-uninstall-and-an-update
 -when-lt-RemoveExi-td5776494.html
 when REP is after InstallInitialize, it can't be done with Component
 conditions.

 So I need a CustomAction which deletes the file and can be conditioned
 to happen only when real uninstalls. Because of that I got to the code
 below, which doesn't work.
 Can somebody pls help me?

 Thanks,
 MeCoco

 On 11/29/2010 2:54 PM, Peter Shirtcliffe wrote:
 Use theRemoveFile   element instead.


 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 29 November 2010 13:45
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] QtExecDeferred and using a property in the cmd
 line
 Hi all,

 I need to delete a specific file (created by our product) after
 uninstalling the product. For that I'm using the Quiet Execution
 CustomAction like:

 Property Id=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/
 /InstallExecuteSequence


 When I'm building this I get the following 2 warnings:

 warning CNDL1077: The 'QtExecDeferred' Property contains
 '[SystemFolder]' in its value which is an illegal reference to another
 property.  If this value is a string literal, not a property
 reference,
 please ignore this warning.  To set a property with the value of
 another
 property, use a CustomAction with Property and Value attributes.
 warning CNDL1077: The 'QtExecDeferred' Property contains
 '[APPLICATIONFOLDER]' in its value which is an illegal reference to
 another property.  If this value is a string literal, not a property
 reference, please ignore this warning.  To set a property with the
 value
 of another property, use a CustomAction with Property and Value
 attributes.

 By looking into the log file, I see that the execution failed, with
 file not found:
 MSI (s) (4C:28) [14:26:46:842]: Executing op:

 CustomActionSchedule(Action=QtExecDeferred,ActionType=3137,Source=Binary
 Data,Target=CAQuietExec,CustomActionData=[SystemFolder]\Cmd.exe
 /C del /Q [INSTALLLOCATION]\momo.txt)
 MSI (s) (4C:80) [14:26:46:853]: Invoking remote custom action. DLL:
 C:\Windows\Installer\MSI8DF2.tmp, Entrypoint: CAQuietExec
 MSI (s) (4C:80) [14:26:46:853]: Generating random cookie.
 MSI (s) (4C:80) [14:26:46:871]: Created Custom Action Server with PID
 7996 (0x1F3C).
 MSI (s) (4C:4C) [14:26:46:973]: Running as a service.
 MSI (s) (4C:4C) [14:26:46:976]: Hello, I'm your 32bit Elevated custom
 action server.
 CAQuietExec:  Error 0x80070002: Command failed to execute.
 CAQuietExec:  Error 0x80070002: CAQuietExec Failed


 I assume the problem is that I'm using [SystemFolder] and
 [INSTALLLOCATION] in a deferred CustomAction.

 By searching the internet I found somebody saying:
You can't access properties directly from a defered custom action.
 You
   have to use another custom action that sets a property matching
 the
 name of
   your action.

 The problem is that I don't know how to do that? Can someone pls,
 taking
 in account the above lines of code, tell me how and what do I need to
 change to follow this instruction?

 Thank you,
 MeCoco

Re: [WiX-users] QtExecDeferred and using a property in the cmd line

2010-11-30 Thread MeCoco
Hi Thomas,

Thanks a lot for posting the code for this. Because I need the CA to be 
run only when uninstall, not also through an update, I conditioned the 
CAs, so the code looks like:

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=RemoveExistingProductsREMOVE=ALL AND NOT 
UPGRADINGPRODUCTCODE/Custom
Custom Action=QtExecDeferred_Cmd Before=QtExecDeferredREMOVE=ALL 
AND NOT UPGRADINGPRODUCTCODE/Custom
/InstallExecuteSequence


and it works as expected.
Thank you,
MeCoco


On 11/29/2010 5:42 PM, Thomas S. Trias wrote:
 It's too bad that RemoveFile won't work, since it does provide 
 appropriate transacted functionality; that said, the answer to using 
 properties within the command line is to use a custom action to set 
 the property value:

 CustomAction Id=SetAspNet20_Cmd Property=SetAspNet20 
 Value=quot;[NETFRAMEWORK20INSTALLROOTDIR]aspnet_regiis.exequot; -ir 
 -enable/
 CustomAction Id=SetAspNet20 BinaryKey=WixCA 
 DllEntry=CAQuietExec Execute=deferred Return=check/

 InstallExecuteSequence
 Custom Action=SetAspNet20_Cmd Before=CostFinalizeNOT 
 (SKIPCONFIGUREIIS OR Installed) AND VersionNT gt; 400/Custom
 Custom Action=SetAspNet20 Before=ConfigureIIsNOT 
 (SKIPCONFIGUREIIS OR Installed) AND VersionNT gt; 400/Custom
 /InstallExecuteSequence

 in your case:

 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_Cmd Before=CostFinalize/
 Custom Action=QtExecDeferred After=RemoveExistingProducts/
 /InstallExecuteSequence

 Thanks,

 Thomas S. Trias
 Senior Developer
 Artizan Internet Services
 http://www.artizan.com/


  Original Message  
 Subject: Re: [WiX-users] QtExecDeferred and using a property in the 
 cmd line
 From: MeCoco vcotirl...@hotmail.com
 To: General discussion for Windows Installer XML toolset.
 wix-users@lists.sourceforge.net
 Date: 11/29/2010 8:25 AM
 Hi Peter.

 Thx for your answer, but I can't do that because I need the files to 
 be removed _only_ when uninstall (not updates) and I have 
 RemoveExistingProducts After=InstallInitialize/. And as I 
 described here:
 http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/BUG-limitation-in-WIX-MSI-No-way-to-distinguish-between-an-uninstall-and-an-update-when-lt-RemoveExi-td5776494.html
  

 when REP is after InstallInitialize, it can't be done with Component 
 conditions.

 So I need a CustomAction which deletes the file and can be 
 conditioned to happen only when real uninstalls. Because of that I 
 got to the code below, which doesn't work.
 Can somebody pls help me?

 Thanks,
 MeCoco

 On 11/29/2010 2:54 PM, Peter Shirtcliffe wrote:
 Use theRemoveFile  element instead.


 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 29 November 2010 13:45
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] QtExecDeferred and using a property in the cmd 
 line

 Hi all,

 I need to delete a specific file (created by our product) after
 uninstalling the product. For that I'm using the Quiet Execution
 CustomAction like:

 Property Id=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/
 /InstallExecuteSequence


 When I'm building this I get the following 2 warnings:

 warning CNDL1077: The 'QtExecDeferred' Property contains
 '[SystemFolder]' in its value which is an illegal reference to another
 property.  If this value is a string literal, not a property reference,
 please ignore this warning.  To set a property with the value of 
 another

 property, use a CustomAction with Property and Value attributes.
 warning CNDL1077: The 'QtExecDeferred' Property contains
 '[APPLICATIONFOLDER]' in its value which is an illegal reference to
 another property.  If this value is a string literal, not a property
 reference, please ignore this warning.  To set a property with the 
 value

 of another property, use a CustomAction with Property and Value
 attributes.

 By looking into the log file, I see that the execution failed, with
 file not found:
 MSI (s) (4C:28) [14:26:46:842]: Executing op:
 CustomActionSchedule(Action=QtExecDeferred,ActionType=3137,Source=Binary 

 Data,Target=CAQuietExec,CustomActionData=[SystemFolder]\Cmd.exe
 /C del /Q [INSTALLLOCATION]\momo.txt)
 MSI (s) (4C:80) [14:26:46:853]: Invoking remote custom action. DLL

[WiX-users] QtExecDeferred and using a property in the cmd line

2010-11-29 Thread MeCoco
Hi all,

I need to delete a specific file (created by our product) after 
uninstalling the product. For that I'm using the Quiet Execution 
CustomAction like:

Property Id=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/
/InstallExecuteSequence


When I'm building this I get the following 2 warnings:

warning CNDL1077: The 'QtExecDeferred' Property contains 
'[SystemFolder]' in its value which is an illegal reference to another 
property.  If this value is a string literal, not a property reference, 
please ignore this warning.  To set a property with the value of another 
property, use a CustomAction with Property and Value attributes.
warning CNDL1077: The 'QtExecDeferred' Property contains 
'[APPLICATIONFOLDER]' in its value which is an illegal reference to 
another property.  If this value is a string literal, not a property 
reference, please ignore this warning.  To set a property with the value 
of another property, use a CustomAction with Property and Value attributes.

By looking into the log file, I see that the execution failed, with 
file not found:
MSI (s) (4C:28) [14:26:46:842]: Executing op: 
CustomActionSchedule(Action=QtExecDeferred,ActionType=3137,Source=BinaryData,Target=CAQuietExec,CustomActionData=[SystemFolder]\Cmd.exe
  
/C del /Q [INSTALLLOCATION]\momo.txt)
MSI (s) (4C:80) [14:26:46:853]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSI8DF2.tmp, Entrypoint: CAQuietExec
MSI (s) (4C:80) [14:26:46:853]: Generating random cookie.
MSI (s) (4C:80) [14:26:46:871]: Created Custom Action Server with PID 
7996 (0x1F3C).
MSI (s) (4C:4C) [14:26:46:973]: Running as a service.
MSI (s) (4C:4C) [14:26:46:976]: Hello, I'm your 32bit Elevated custom 
action server.
CAQuietExec:  Error 0x80070002: Command failed to execute.
CAQuietExec:  Error 0x80070002: CAQuietExec Failed


I assume the problem is that I'm using [SystemFolder] and 
[INSTALLLOCATION] in a deferred CustomAction.

By searching the internet I found somebody saying:
 You can't access properties directly from a defered custom action.  You
  have to use another custom action that sets a property matching the 
name of
  your action.

The problem is that I don't know how to do that? Can someone pls, taking 
in account the above lines of code, tell me how and what do I need to 
change to follow this instruction?

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


Re: [WiX-users] QtExecDeferred and using a property in the cmd line

2010-11-29 Thread MeCoco
Hi Peter.

Thx for your answer, but I can't do that because I need the files to be 
removed _only_ when uninstall (not updates) and I have 
RemoveExistingProducts After=InstallInitialize/. And as I described 
here:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/BUG-limitation-in-WIX-MSI-No-way-to-distinguish-between-an-uninstall-and-an-update-when-lt-RemoveExi-td5776494.html
when REP is after InstallInitialize, it can't be done with Component 
conditions.

So I need a CustomAction which deletes the file and can be conditioned 
to happen only when real uninstalls. Because of that I got to the code 
below, which doesn't work.
Can somebody pls help me?

Thanks,
MeCoco

On 11/29/2010 2:54 PM, Peter Shirtcliffe wrote:
 Use theRemoveFile  element instead.


 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 29 November 2010 13:45
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] QtExecDeferred and using a property in the cmd line

 Hi all,

 I need to delete a specific file (created by our product) after
 uninstalling the product. For that I'm using the Quiet Execution
 CustomAction like:

 Property Id=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/
 /InstallExecuteSequence


 When I'm building this I get the following 2 warnings:

 warning CNDL1077: The 'QtExecDeferred' Property contains
 '[SystemFolder]' in its value which is an illegal reference to another
 property.  If this value is a string literal, not a property reference,
 please ignore this warning.  To set a property with the value of another

 property, use a CustomAction with Property and Value attributes.
 warning CNDL1077: The 'QtExecDeferred' Property contains
 '[APPLICATIONFOLDER]' in its value which is an illegal reference to
 another property.  If this value is a string literal, not a property
 reference, please ignore this warning.  To set a property with the value

 of another property, use a CustomAction with Property and Value
 attributes.

 By looking into the log file, I see that the execution failed, with
 file not found:
 MSI (s) (4C:28) [14:26:46:842]: Executing op:
 CustomActionSchedule(Action=QtExecDeferred,ActionType=3137,Source=Binary
 Data,Target=CAQuietExec,CustomActionData=[SystemFolder]\Cmd.exe
 /C del /Q [INSTALLLOCATION]\momo.txt)
 MSI (s) (4C:80) [14:26:46:853]: Invoking remote custom action. DLL:
 C:\Windows\Installer\MSI8DF2.tmp, Entrypoint: CAQuietExec
 MSI (s) (4C:80) [14:26:46:853]: Generating random cookie.
 MSI (s) (4C:80) [14:26:46:871]: Created Custom Action Server with PID
 7996 (0x1F3C).
 MSI (s) (4C:4C) [14:26:46:973]: Running as a service.
 MSI (s) (4C:4C) [14:26:46:976]: Hello, I'm your 32bit Elevated custom
 action server.
 CAQuietExec:  Error 0x80070002: Command failed to execute.
 CAQuietExec:  Error 0x80070002: CAQuietExec Failed


 I assume the problem is that I'm using [SystemFolder] and
 [INSTALLLOCATION] in a deferred CustomAction.

 By searching the internet I found somebody saying:
   You can't access properties directly from a defered custom action.
 You
 have to use another custom action that sets a property matching the
 name of
 your action.

 The problem is that I don't know how to do that? Can someone pls, taking

 in account the above lines of code, tell me how and what do I need to
 change to follow this instruction?

 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
 SDL PLC confidential, all rights reserved.
 If you are not the intended recipient of this mail SDL requests and requires 
 that you delete it without acting upon or copying any of its contents, and we 
 further request that you advise us.
 SDL PLC is a public limited company registered in England and Wales.  
 Registered number: 02675207.
 Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 
 7DY, UK.


 --
 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

Re: [WiX-users] [BUG/limitation in WIX/MSI]No way to distinguish between an uninstall and an update when RemoveExistingProducts After=InstallInitialize/

2010-11-29 Thread MeCoco
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, MeCocovcotirl...@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}
 INSTALLLOCATION0(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,
 egRemoveExistingProducts 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

[WiX-users] [BUG/limitation in WIX/MSI]No way to distinguish between an uninstall and an update when RemoveExistingProducts After=InstallInitialize/

2010-11-26 Thread MeCoco
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=AppSearchNEWAPPFOUND/Custom
Custom Action=CurrentVersionDetected After=AppSearchSELFFOUND/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=InstallValidateNOT 
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

Re: [WiX-users] [BUG/limitation in WIX/MSI]No way to distinguish between an uninstall and an update when RemoveExistingProducts After=InstallInitialize/

2010-11-26 Thread MeCoco
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}
INSTALLLOCATION0(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,
 egRemoveExistingProducts 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 havingRemoveExistingProducts
 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=AppSearchNEWAPPFOUND/Custom
 Custom Action=CurrentVersionDetected After=AppSearchSELFFOUND/Custom
 RemoveExistingProducts After=InstallInitialize/
 !--RemoveExistingProducts After=InstallFinalize/--
 /InstallExecuteSequence

Re: [WiX-users] If file exists, don't update another file

2010-11-25 Thread MeCoco
Actually the code:

Component Id=RemoveLogosFile Guid=PUT_MY_GUID
   RemoveFile Id=RemoveLogosFile Name=MyLogo.jpg On=uninstall/
   RemoveFile Id=RemoveBundleFile Name=bundle On=uninstall/
   Condition(NOT UPGRADINGPRODUCTCODE) AND (REMOVE=ALL)/Condition
/Component

works as expected _if_:
RemoveExistingProducts After=InstallFinalize/

meaning the 2 files are deleted _only_ during an uninstall from add/remove 
product and they _don't_ get deleted during an update.

But in my installer I have:
RemoveExistingProducts After=InstallInitialize/

and the behavior in this case is that the 2 files are _always_ deleted 
regardless if it's an update or removal from add/remove programs.

Can somebody help me accomplish the deletion of those files only when 
uninstalling from add/remove programs and not during an update when having
RemoveExistingProducts After=InstallInitialize/?

Thank you,
MeCoco


On 11/24/2010 4:10 PM, MeCoco wrote:
 Hi Blair,

 I seem to still have a problem: because I want the files that were
 placed with an empty GUID to be deleted when a real uninstall  happens
 (not update or repair, but an uninstall from add/remove programs), I
 also added the code:

 Component Id=RemoveLogosFile Guid=PUT_MY_GUID
 RemoveFile Id=RemoveLogosFile Name=MyLogo.jpg On=uninstall/
 RemoveFile Id=RemoveBundleFile Name=bundle On=uninstall/
 Condition(NOT UPGRADINGPRODUCTCODE) AND (REMOVE=ALL)/Condition
 /Component

 but this code makes that after an update to end up without the 2 files:
 MyLogo.jpg and bundle. For some reason the condition seems to be
 evaluated to TRUE even when I'm running an update so these 2 files are
 always deleted.

 (Not sure if it's worth mentioning, but I still have the :
 RemoveExistingProducts After=InstallInitialize/)

 Am I doing something wrong here?

 Thank you,
 MeCoco


 On 11/24/2010 2:39 PM, MeCoco wrote:
 Hi Blair,

 Thanks a lot for your answer! That was exactly the code I just wrote and
 I was testing just now all of the scenarios.

 Thanks,
 MeCoco

 On 11/24/2010 1:23 PM, Blair wrote:
 In the original MSI you give to your sales people, create the MyLogo
 component with an empty guid. It will get left behind, and the presence of
 the bundle file will prevent its overwrite.

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: Wednesday, November 24, 2010 1:22 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] If file exists, don't update another file

 Hi Blair,

 First of all I have to mention that the partner problem is just for our
 sale people. To make everything clearer: all the clients, which mean
 _our_ and _their_ clients, will have _our_ logo, so I need a
 workaround only for our sale people, who for whatever reason want only
 for their demo systems to NOT have the partner logo updated. Being _our_
 sale people, meaning only a few people, I should find a workaround that
 do not disturb at all the already written and tested installer as it is
 now provided to all our clients.
 Because of that I actually thought like this:
 - for the sales people I will build a first time installer containing
 the exact same files like the normal installer, only that the mylogo.jpg
 content is different and also a dummy file, let's name it bundle, gets
 also installed
 - they use this installer, install the product on their demo systems
 - after this point, any update we provide for _our_ clients should be
 used also by these sales ppl, with the point that mylogo.jpg in _their_
 cases should not be updated

 This is the request, so I was thinking: in the first time installer that
 we give _just_ to our sales people, the dumy file bundle gets
 installed and any later update (update that should be identical for our
 sale people and our clients) should take care not to update the
 mylogo.jpg if the bundle file is found, b/c then it's our sales
 people. In case the bundle file is not there, meaning is a client not a
 sales person, then the mylogo.jpg should be updated.

 Also I have to leave the:
 RemoveExistingProducts After=InstallInitialize/
 untouched.

 Now, back to your answser Blair:
 Do a FileSearch for the specific file, and based on that property
 condition your logo component to not install.

 I tried that:

 1) I created a first time installer which was placing also a dummy
 bundle file into the install directory
 Component Id=MyLogo.jpg Guid=PUT-MY-GUID1
 File Id=MyLogo.jpg Source=MyLogo.jpg KeyPath=yes Checksum=yes /
 /Component
 Component Id=bundle Guid=PUT-MY-GUID2
 File Id=bundle Source=bundle KeyPath=yes Checksum=yes /
 /Component


 2) Then created the update which will be used by everybody: clients and
 sales people

 !-- Search the bundle file --
 Property Id='FILE_BUNDLE_EXISTS'
 DirectorySearch Id='DirSearch' Path='[INSTALLDIR]' Depth='0'
 FileSearch Id='FileSearch' Name='bundle'/
 /DirectorySearch
 /Property

 Component Id=MyLogo.jpg Guid=PUT-MY-GUID1
 File Id=MyLogo.jpg Source=MyLogo.jpg

[WiX-users] Remove files only when uninstall, when having REP after InstallInitialize

2010-11-25 Thread MeCoco
Hi all,

I have to accomplish the following: when the product gets completelly 
uninstalled (from add/remove programs, _not_ during an update) I need to 
specifically delete 2 additional files.

For that I have the following code:

Component Id=RemoveLogosFile Guid=PUT_MY_GUID 
RemoveFile Id=RemoveLogosFile Name=MyLogo.jpg On=uninstall/
RemoveFile Id=RemoveBundleFile Name=bundle On=uninstall/
Condition(NOT UPGRADINGPRODUCTCODE) AND (REMOVE=ALL)/Condition
/Component

The above code works as expected _if_:
RemoveExistingProducts After=InstallFinalize/

meaning the 2 files are deleted _only_ during an uninstall from 
add/remove programs and they _don't_ get deleted during an update.

But in my installer I have:
RemoveExistingProducts After=InstallInitialize/

and the behavior in this case is that the 2 files are _always_ deleted 
regardless if it's an update or removal from add/remove programs.

Can somebody help me accomplish the deletion of those files only when 
uninstalling from add/remove programs and not during an update, when having
RemoveExistingProducts After=InstallInitialize/?

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


Re: [WiX-users] Remove files only when uninstall, when having REP after InstallInitialize

2010-11-25 Thread MeCoco
Hi all,

I created a small sample file that shows exactly my 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
3) run version 1.0.0 = the product will be installed
4) In C:\Program Files\MySmallProject add a dummy file: momo.txt
5) run the second version 101, which _updates_ the product

= the momo.txt is gone!!

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.

Is this maybe a bug in wix/msi? or am I doing something wrong?

I have to have in the installer the:
RemoveExistingProducts After=InstallInitialize/

so, can somebody point me out a way of doing this also when: 
RemoveExistingProducts After=InstallInitialize/?

Thank you,
MeCoco

The code:

?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=AppSearchNEWAPPFOUND/Custom
Custom Action=CurrentVersionDetected After=AppSearchSELFFOUND/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=InstallValidateNOT 
Installed/Custom
/InstallExecuteSequence

/Product
/Wix



On 11/25/2010 12:41 PM, MeCoco wrote:
 Hi all,

 I have to accomplish the following: when the product gets completelly
 uninstalled (from add/remove programs, _not_ during an update) I need to
 specifically delete 2 additional files.

 For that I have the following code:

 Component Id=RemoveLogosFile Guid=PUT_MY_GUID
 RemoveFile Id=RemoveLogosFile Name=MyLogo.jpg On=uninstall/
 RemoveFile Id=RemoveBundleFile Name=bundle On=uninstall/
 Condition(NOT UPGRADINGPRODUCTCODE) AND (REMOVE=ALL)/Condition
 /Component

 The above code works as expected _if_:
 RemoveExistingProducts After=InstallFinalize/

 meaning the 2 files are deleted _only_ during an uninstall from
 add/remove programs and they _don't_ get deleted during an update.

 But in my installer I have:
 RemoveExistingProducts After=InstallInitialize/

 and the behavior in this case is that the 2 files are _always_ deleted
 regardless if it's an update or removal from add/remove programs.

 Can somebody help me accomplish the deletion of those files only when
 uninstalling from add/remove programs and not during an update, when having
 RemoveExistingProducts After=InstallInitialize/?

 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

Re: [WiX-users] If file exists, don't update another file

2010-11-24 Thread MeCoco
Hi Blair,

First of all I have to mention that the partner problem is just for our 
sale people. To make everything clearer: all the clients, which mean 
_our_ and _their_ clients, will have _our_ logo, so I need a 
workaround only for our sale people, who for whatever reason want only 
for their demo systems to NOT have the partner logo updated. Being _our_ 
sale people, meaning only a few people, I should find a workaround that 
do not disturb at all the already written and tested installer as it is 
now provided to all our clients.
Because of that I actually thought like this:
- for the sales people I will build a first time installer containing 
the exact same files like the normal installer, only that the mylogo.jpg 
content is different and also a dummy file, let's name it bundle, gets 
also installed
- they use this installer, install the product on their demo systems
- after this point, any update we provide for _our_ clients should be 
used also by these sales ppl, with the point that mylogo.jpg in _their_ 
cases should not be updated

This is the request, so I was thinking: in the first time installer that 
we give _just_ to our sales people, the dumy file bundle gets 
installed and any later update (update that should be identical for our 
sale people and our clients) should take care not to update the 
mylogo.jpg if the bundle file is found, b/c then it's our sales 
people. In case the bundle file is not there, meaning is a client not a 
sales person, then the mylogo.jpg should be updated.

Also I have to leave the:
RemoveExistingProducts After=InstallInitialize/
untouched.

Now, back to your answser Blair:
  Do a FileSearch for the specific file, and based on that property 
condition your logo component to not install.

I tried that:

1) I created a first time installer which was placing also a dummy 
bundle file into the install directory
Component Id=MyLogo.jpg Guid=PUT-MY-GUID1
File Id=MyLogo.jpg Source=MyLogo.jpg KeyPath=yes Checksum=yes /
/Component
Component Id=bundle Guid=PUT-MY-GUID2
File Id=bundle Source=bundle KeyPath=yes Checksum=yes /
/Component


2) Then created the update which will be used by everybody: clients and 
sales people

!-- Search the bundle file --
Property Id='FILE_BUNDLE_EXISTS'
DirectorySearch Id='DirSearch' Path='[INSTALLDIR]' Depth='0'
FileSearch Id='FileSearch' Name='bundle'/
/DirectorySearch
/Property

Component Id=MyLogo.jpg Guid=PUT-MY-GUID1
File Id=MyLogo.jpg Source=MyLogo.jpg KeyPath=yes Checksum=yes /
Condition(NOT FILE_BUNDLE_EXISTS)/Condition
/Component
Component Id=bundle Guid=PUT-MY-GUID2
File Id=bundle Source=bundle KeyPath=yes Checksum=yes /
ConditionFILE_BUNDLE_EXISTS/Condition
/Component

But after running the update I ended up by not having the MyLogo.jpg 
installed at all.

Is there any other way to accomplish this?

Thank you!
MeCoco


On 11/24/2010 2:48 AM, Blair wrote:
 Do a FileSearch for the specific file, and based on that property condition
 your logo component to not install.

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: Tuesday, November 23, 2010 6:35 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] If file exists, don't update another file

 Hi Dave,

 I can't do that. Here is the explanation: we have a product which we
 release to different clients. We also have a partner with whom we
 bundle, so he wants to offer our product together with his, but the logo
 should stay his logo. We can't have his logo and our logo in the
 installer, as we don't want the clients digging that up.
 So we agreed on the following: first time when he installs the product
 he places a dummy file.txt into the installation directory and his own
 logo. When we provide an installer which is upgrading our software, in
 case the update is for our own clients, the logo should be updated, but
 if the upgrade is run by the partner-client the logo shouldn't be
 updated, so basically our update should check if the file.txt is there
 and if yes should not update the logo.

 In other words: if in the installation folder there is a specific file,
 eg file.txt, then a specific file, eg mylogo.jpg should _not_ be updated.

 And I'm not sure how one can do that when:
 RemoveExistingProducts After=InstallInitialize/
 as from what I read, the product is completely removed first so his logo
 will be gone.

 Thank you,
 MeCoco



 On 11/23/2010 2:59 PM, David Watson wrote:
 Why not include both logos in your new msi and install only one
 conditionally.

 Dave

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 23 November 2010 13:04
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] If file exists, don't update another file

 Hi all,

 I have to do the following: if in the installation folder there is a
 specific file, eg file.txt, then a specific file, eg mylogo.jpg should
 _not_ be updated.
 The installer is doing always major upgrades.

 My

Re: [WiX-users] If file exists, don't update another file

2010-11-24 Thread MeCoco
I am not familiar with merge module, but taking in account the scenario 
I described as a reply to Blair's email (same thread), do you think it 
would help me?

I will actually put here the reply to Blair's email just for easier 
reference:

First of all I have to mention that the partner problem is just for our 
sale people. To make everything clearer: all the clients, which mean 
_our_ and _their_ clients, will have _our_ logo, so I need a 
workaround only for our sale people, who for whatever reason want only 
for their demo systems to NOT have the partner logo updated. Being _our_ 
sale people, meaning only a few people, I should find a workaround that 
do not disturb at all the already written and tested installer as it is 
now provided to all our clients.
Because of that I actually thought like this:
- for the sales people I will build a first time installer containing 
the exact same files like the normal installer, only that the mylogo.jpg 
content is different and also a dummy file, let's name it bundle, gets 
also installed
- they use this installer, install the product on their demo systems
- after this point, any update we provide for _our_ clients should be 
used also by these sales ppl, with the point that mylogo.jpg in _their_ 
cases should not be updated

This is the request, so I was thinking: in the first time installer that 
we give _just_ to our sales people, the dumy file bundle gets 
installed and any later update (update that should be identical for our 
sale people and our clients) should take care not to update the 
mylogo.jpg if the bundle file is found, b/c then it's our sales 
people. In case the bundle file is not there, meaning is a client not a 
sales person, then the mylogo.jpg should be updated.

Also I have to leave the:
RemoveExistingProducts After=InstallInitialize/
untouched. 

Important thing is: I'm allowed to do a first time installer for our 
sales people which is different then the rest, but the updates should be 
identical for clients and sales people, and the sales people shouldn't 
have to do anything after an update.

Thank you!
MeCoco


On 11/23/2010 4:43 PM, Wheeler, Blaine (DSHS/DCS) wrote:
 Why not give your partner a merge-module or wixlib.   That way he is can
 control which version of your product goes with which version of his and
 it solves the logo problem

 Your build consumes the same thing you give the partner and then adds
 your logo

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: Tuesday, November 23, 2010 6:35 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] If file exists, don't update another file

 Hi Dave,

 I can't do that. Here is the explanation: we have a product which we
 release to different clients. We also have a partner with whom we
 bundle, so he wants to offer our product together with his, but the logo

 should stay his logo. We can't have his logo and our logo in the
 installer, as we don't want the clients digging that up.
 So we agreed on the following: first time when he installs the product
 he places a dummy file.txt into the installation directory and his own
 logo. When we provide an installer which is upgrading our software, in
 case the update is for our own clients, the logo should be updated, but
 if the upgrade is run by the partner-client the logo shouldn't be
 updated, so basically our update should check if the file.txt is there
 and if yes should not update the logo.

 In other words: if in the installation folder there is a specific file,
 eg file.txt, then a specific file, eg mylogo.jpg should _not_ be
 updated.

 And I'm not sure how one can do that when:
 RemoveExistingProducts After=InstallInitialize/
 as from what I read, the product is completely removed first so his logo

 will be gone.

 Thank you,
 MeCoco



 On 11/23/2010 2:59 PM, David Watson wrote:
 Why not include both logos in your new msi and install only one
 conditionally.

 Dave

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 23 November 2010 13:04
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] If file exists, don't update another file

 Hi all,

 I have to do the following: if in the installation folder there is a
 specific file, eg file.txt, then a specific file, eg mylogo.jpg should
 _not_ be updated.
 The installer is doing always major upgrades.

 My question is: assuming that the request can be done by using a
 conditional component (not yet sure how, but this is another story)
 could I do that if in the installer I have:
 RemoveExistingProducts After=InstallInitialize/? Or this won't
 work
 because the product is first completely removed and only then the new
 version installed, so basically the mylogo.jpg is gone as part of
 removing old products, so it won't be preserved, so the new one, the
 one
 from the package will be installed?

 If what I wrote above is correct, is there any other way

Re: [WiX-users] If file exists, don't update another file

2010-11-24 Thread MeCoco
Hi Blair,

Thanks a lot for your answer! That was exactly the code I just wrote and 
I was testing just now all of the scenarios.

Thanks,
MeCoco

On 11/24/2010 1:23 PM, Blair wrote:
 In the original MSI you give to your sales people, create the MyLogo
 component with an empty guid. It will get left behind, and the presence of
 the bundle file will prevent its overwrite.

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: Wednesday, November 24, 2010 1:22 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] If file exists, don't update another file

 Hi Blair,

 First of all I have to mention that the partner problem is just for our
 sale people. To make everything clearer: all the clients, which mean
 _our_ and _their_ clients, will have _our_ logo, so I need a
 workaround only for our sale people, who for whatever reason want only
 for their demo systems to NOT have the partner logo updated. Being _our_
 sale people, meaning only a few people, I should find a workaround that
 do not disturb at all the already written and tested installer as it is
 now provided to all our clients.
 Because of that I actually thought like this:
 - for the sales people I will build a first time installer containing
 the exact same files like the normal installer, only that the mylogo.jpg
 content is different and also a dummy file, let's name it bundle, gets
 also installed
 - they use this installer, install the product on their demo systems
 - after this point, any update we provide for _our_ clients should be
 used also by these sales ppl, with the point that mylogo.jpg in _their_
 cases should not be updated

 This is the request, so I was thinking: in the first time installer that
 we give _just_ to our sales people, the dumy file bundle gets
 installed and any later update (update that should be identical for our
 sale people and our clients) should take care not to update the
 mylogo.jpg if the bundle file is found, b/c then it's our sales
 people. In case the bundle file is not there, meaning is a client not a
 sales person, then the mylogo.jpg should be updated.

 Also I have to leave the:
 RemoveExistingProducts After=InstallInitialize/
 untouched.

 Now, back to your answser Blair:
 Do a FileSearch for the specific file, and based on that property
 condition your logo component to not install.

 I tried that:

 1) I created a first time installer which was placing also a dummy
 bundle file into the install directory
 Component Id=MyLogo.jpg Guid=PUT-MY-GUID1
 File Id=MyLogo.jpg Source=MyLogo.jpg KeyPath=yes Checksum=yes /
 /Component
 Component Id=bundle Guid=PUT-MY-GUID2
 File Id=bundle Source=bundle KeyPath=yes Checksum=yes /
 /Component


 2) Then created the update which will be used by everybody: clients and
 sales people

 !-- Search the bundle file --
 Property Id='FILE_BUNDLE_EXISTS'
 DirectorySearch Id='DirSearch' Path='[INSTALLDIR]' Depth='0'
 FileSearch Id='FileSearch' Name='bundle'/
 /DirectorySearch
 /Property

 Component Id=MyLogo.jpg Guid=PUT-MY-GUID1
 File Id=MyLogo.jpg Source=MyLogo.jpg KeyPath=yes Checksum=yes /
 Condition(NOT FILE_BUNDLE_EXISTS)/Condition
 /Component
 Component Id=bundle Guid=PUT-MY-GUID2
 File Id=bundle Source=bundle KeyPath=yes Checksum=yes /
 ConditionFILE_BUNDLE_EXISTS/Condition
 /Component

 But after running the update I ended up by not having the MyLogo.jpg
 installed at all.

 Is there any other way to accomplish this?

 Thank you!
 MeCoco


 On 11/24/2010 2:48 AM, Blair wrote:
 Do a FileSearch for the specific file, and based on that property
 condition
 your logo component to not install.

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: Tuesday, November 23, 2010 6:35 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] If file exists, don't update another file

 Hi Dave,

 I can't do that. Here is the explanation: we have a product which we
 release to different clients. We also have a partner with whom we
 bundle, so he wants to offer our product together with his, but the logo
 should stay his logo. We can't have his logo and our logo in the
 installer, as we don't want the clients digging that up.
 So we agreed on the following: first time when he installs the product
 he places a dummy file.txt into the installation directory and his own
 logo. When we provide an installer which is upgrading our software, in
 case the update is for our own clients, the logo should be updated, but
 if the upgrade is run by the partner-client the logo shouldn't be
 updated, so basically our update should check if the file.txt is there
 and if yes should not update the logo.

 In other words: if in the installation folder there is a specific file,
 eg file.txt, then a specific file, eg mylogo.jpg should _not_ be updated.

 And I'm not sure how one can do that when:
 RemoveExistingProducts After=InstallInitialize/
 as from what I read, the product

Re: [WiX-users] If file exists, don't update another file

2010-11-24 Thread MeCoco
Hi Blair,

I seem to still have a problem: because I want the files that were 
placed with an empty GUID to be deleted when a real uninstall  happens 
(not update or repair, but an uninstall from add/remove programs), I 
also added the code:

Component Id=RemoveLogosFile Guid=PUT_MY_GUID 
RemoveFile Id=RemoveLogosFile Name=MyLogo.jpg On=uninstall/
RemoveFile Id=RemoveBundleFile Name=bundle On=uninstall/
Condition(NOT UPGRADINGPRODUCTCODE) AND (REMOVE=ALL)/Condition
/Component

but this code makes that after an update to end up without the 2 files: 
MyLogo.jpg and bundle. For some reason the condition seems to be 
evaluated to TRUE even when I'm running an update so these 2 files are 
always deleted.

(Not sure if it's worth mentioning, but I still have the : 
RemoveExistingProducts After=InstallInitialize/)

Am I doing something wrong here?

Thank you,
MeCoco


On 11/24/2010 2:39 PM, MeCoco wrote:
 Hi Blair,

 Thanks a lot for your answer! That was exactly the code I just wrote and
 I was testing just now all of the scenarios.

 Thanks,
 MeCoco

 On 11/24/2010 1:23 PM, Blair wrote:
 In the original MSI you give to your sales people, create the MyLogo
 component with an empty guid. It will get left behind, and the presence of
 the bundle file will prevent its overwrite.

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: Wednesday, November 24, 2010 1:22 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] If file exists, don't update another file

 Hi Blair,

 First of all I have to mention that the partner problem is just for our
 sale people. To make everything clearer: all the clients, which mean
 _our_ and _their_ clients, will have _our_ logo, so I need a
 workaround only for our sale people, who for whatever reason want only
 for their demo systems to NOT have the partner logo updated. Being _our_
 sale people, meaning only a few people, I should find a workaround that
 do not disturb at all the already written and tested installer as it is
 now provided to all our clients.
 Because of that I actually thought like this:
 - for the sales people I will build a first time installer containing
 the exact same files like the normal installer, only that the mylogo.jpg
 content is different and also a dummy file, let's name it bundle, gets
 also installed
 - they use this installer, install the product on their demo systems
 - after this point, any update we provide for _our_ clients should be
 used also by these sales ppl, with the point that mylogo.jpg in _their_
 cases should not be updated

 This is the request, so I was thinking: in the first time installer that
 we give _just_ to our sales people, the dumy file bundle gets
 installed and any later update (update that should be identical for our
 sale people and our clients) should take care not to update the
 mylogo.jpg if the bundle file is found, b/c then it's our sales
 people. In case the bundle file is not there, meaning is a client not a
 sales person, then the mylogo.jpg should be updated.

 Also I have to leave the:
 RemoveExistingProducts After=InstallInitialize/
 untouched.

 Now, back to your answser Blair:
   Do a FileSearch for the specific file, and based on that property
 condition your logo component to not install.

 I tried that:

 1) I created a first time installer which was placing also a dummy
 bundle file into the install directory
 Component Id=MyLogo.jpg Guid=PUT-MY-GUID1
 File Id=MyLogo.jpg Source=MyLogo.jpg KeyPath=yes Checksum=yes /
 /Component
 Component Id=bundle Guid=PUT-MY-GUID2
 File Id=bundle Source=bundle KeyPath=yes Checksum=yes /
 /Component


 2) Then created the update which will be used by everybody: clients and
 sales people

 !-- Search the bundle file --
 Property Id='FILE_BUNDLE_EXISTS'
 DirectorySearch Id='DirSearch' Path='[INSTALLDIR]' Depth='0'
 FileSearch Id='FileSearch' Name='bundle'/
 /DirectorySearch
 /Property

 Component Id=MyLogo.jpg Guid=PUT-MY-GUID1
 File Id=MyLogo.jpg Source=MyLogo.jpg KeyPath=yes Checksum=yes /
 Condition(NOT FILE_BUNDLE_EXISTS)/Condition
 /Component
 Component Id=bundle Guid=PUT-MY-GUID2
 File Id=bundle Source=bundle KeyPath=yes Checksum=yes /
 ConditionFILE_BUNDLE_EXISTS/Condition
 /Component

 But after running the update I ended up by not having the MyLogo.jpg
 installed at all.

 Is there any other way to accomplish this?

 Thank you!
 MeCoco


 On 11/24/2010 2:48 AM, Blair wrote:
 Do a FileSearch for the specific file, and based on that property
 condition
 your logo component to not install.

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: Tuesday, November 23, 2010 6:35 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] If file exists, don't update another file

 Hi Dave,

 I can't do that. Here is the explanation: we have a product which we
 release to different clients. We also have a partner with whom we
 bundle, so he wants

[WiX-users] If file exists, don't update another file

2010-11-23 Thread MeCoco
Hi all,

I have to do the following: if in the installation folder there is a 
specific file, eg file.txt, then a specific file, eg mylogo.jpg should 
_not_ be updated.
The installer is doing always major upgrades.

My question is: assuming that the request can be done by using a 
conditional component (not yet sure how, but this is another story) 
could I do that if in the installer I have:
RemoveExistingProducts After=InstallInitialize/? Or this won't work 
because the product is first completely removed and only then the new 
version installed, so basically the mylogo.jpg is gone as part of 
removing old products, so it won't be preserved, so the new one, the one 
from the package will be installed?

If what I wrote above is correct, is there any other way to implement 
the above request (if in the installation folder there is a specific 
file, eg file.txt, then a specific file, eg mylogo.jpg should _not_ be 
updated) without changing the:
RemoveExistingProducts After=InstallInitialize/? (I'm not allowed to 
change the place of the removing old products)

Thank you in advance,
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


Re: [WiX-users] If file exists, don't update another file

2010-11-23 Thread MeCoco
Hi Dave,

I can't do that. Here is the explanation: we have a product which we 
release to different clients. We also have a partner with whom we 
bundle, so he wants to offer our product together with his, but the logo 
should stay his logo. We can't have his logo and our logo in the 
installer, as we don't want the clients digging that up.
So we agreed on the following: first time when he installs the product 
he places a dummy file.txt into the installation directory and his own 
logo. When we provide an installer which is upgrading our software, in 
case the update is for our own clients, the logo should be updated, but 
if the upgrade is run by the partner-client the logo shouldn't be 
updated, so basically our update should check if the file.txt is there 
and if yes should not update the logo.

In other words: if in the installation folder there is a specific file, 
eg file.txt, then a specific file, eg mylogo.jpg should _not_ be updated.

And I'm not sure how one can do that when:
RemoveExistingProducts After=InstallInitialize/
as from what I read, the product is completely removed first so his logo 
will be gone.

Thank you,
MeCoco



On 11/23/2010 2:59 PM, David Watson wrote:
 Why not include both logos in your new msi and install only one
 conditionally.

 Dave

 -Original Message-
 From: MeCoco [mailto:vcotirl...@hotmail.com]
 Sent: 23 November 2010 13:04
 To: General discussion for Windows Installer XML toolset.
 Subject: [WiX-users] If file exists, don't update another file

 Hi all,

 I have to do the following: if in the installation folder there is a
 specific file, eg file.txt, then a specific file, eg mylogo.jpg should
 _not_ be updated.
 The installer is doing always major upgrades.

 My question is: assuming that the request can be done by using a
 conditional component (not yet sure how, but this is another story)
 could I do that if in the installer I have:
 RemoveExistingProducts After=InstallInitialize/? Or this won't work
 because the product is first completely removed and only then the new
 version installed, so basically the mylogo.jpg is gone as part of
 removing old products, so it won't be preserved, so the new one, the one

 from the package will be installed?

 If what I wrote above is correct, is there any other way to implement
 the above request (if in the installation folder there is a specific
 file, eg file.txt, then a specific file, eg mylogo.jpg should _not_ be
 updated) without changing the:
 RemoveExistingProducts After=InstallInitialize/? (I'm not allowed to

 change the place of the removing old products)

 Thank you in advance,
 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
 SDL PLC confidential, all rights reserved.
 If you are not the intended recipient of this mail SDL requests and requires 
 that you delete it without acting upon or copying any of its contents, and we 
 further request that you advise us.
 SDL PLC is a public limited company registered in England and Wales.  
 Registered number: 02675207.
 Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 
 7DY, UK.


 --
 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