Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one)
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)
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)
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)
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)
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
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
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
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
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
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
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/
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
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
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
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
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
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/
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/
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/
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
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
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
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
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
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
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
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
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
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
