Re: [WiX-users] Remove section using XMLConfig
Please keep wix-users on the thread so everyone can participate. My solution is already mentioned in the thread BTW I am using Wix v2 (and have no experience with Wix v3) I found the solution: XML file: ?xml version=1.0? dpInst search subDirectoryDirOne/subDirectory subDirectoryDirTwo/subDirectory /search suppressAddRemovePrograms/ quietInstall/ /dpInst To remove the line subDirectoryDirTwo/subDirectory you need to write the XMLConfig in following way: File Id='XmlSettings' Name='dpinst.xml' DiskId='1' / XmlConfig Id='RemoveOneLine' File='[#XmlSettings] ' Action='delete' ElementPath='//dpInst/search' VerifyPath='subDirectory[\[].=DirTwo[\]]' Node='element' On='install' Sequence='1' / Hope that it will help somebody... Stefan Ravikumar Gopinath wrote: Hi, I am trying to remove a section using XmlConfig and it isn't working for me. Can you please let m know how you resolved this issue? I am using the following piece of code: Component Id=WHManagerXml_$(var.LCID) DiskId=1 Guid=111BCB33-664E-42ca-A186-DE04C317681D File Id=TestxmlFile Name=test.xml Source=test.xml/ util:XmlConfig Id=TestXmlChange File=[TestxmlFile] Action=delete Node=element ElementPath=Parent/Descendant1 VerifyPath='[EMAIL PROTECTED]abcd[\]] / /Component My Xml is Parent Descendant1 Descendant2 guid='abcd' / Descendant2 guid='efgh' / /Descendant1 /Parent Thanks Ravi -- Stefan Pavlik | [EMAIL PROTECTED] Whitestein Technologies s.r.o. | www.whitestein.com Panenska 28 | 811 03 Bratislava | Slovak Republic Main +421 2 5443-5502 | Direct +421 2 5930-0735 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Modifying parameters and sending them to a custom action on a button press
Bob Arnson-6 wrote: That's the general model. What problem are you running into? I want to be able to send the c++ function a dynamic property, as in: BROWSEPROPERTY holds the name of another property such as MAINDIR so when a button is pressed the following action sequence will occour*: 1. BROWSEPROPERTY will be set to MAINDIR 2. The c++ function will be called via a custom action *Note: where MAINDIR is being set, this could be another property name such as EXAMPLEDIR which means in the c++ function I will want to have to retrieve the value of MAINDIR TCHAR szBrowseProperty[MAX_PATH]; TCHAR szDirectory[MAX_PATH]; DWORD dwBrowseProperty = MAX_PATH; DWORD dwDirectory = MAX_PATH; MsiGetProperty(hInstall, _T(BROWSEPROPERTY), szBrowseProperty, dwBrowseProperty); MsiGetProperty(hInstall, szBrowseProperty, szDirectory, dwDirectory); the value of MAINDIR will now be in szDirectory and I can work with it. -- View this message in context: http://www.nabble.com/Modifying-parameters-and-sending-them-to-a-custom-action-on-a-button-press-tf4593717.html#a13132134 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Newbie Q - changing TARGETDIR based on mode
Hello, sorry for asking a newbie question; but googling didn't help much. Could somebody please point me to an example that allows specific path for TARGETDIR dir when running msiexec with /quiet switch and offers a different default TARGETDIR path when run interactively? Many thanks, R.- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Modifying parameters and sending them to a custom action on a button press
I think I figured out my error. I wasn't putting a 1 in the content of the publish element. the solution I came up with was to do the following Publish Property=BROWSEPROPERTY Value=MAINDIR1/Publish Publish Event=DoAction Value=ShowBrowseDialog1/Publish -- View this message in context: http://www.nabble.com/Modifying-parameters-and-sending-them-to-a-custom-action-on-a-button-press-tf4593717.html#a13133443 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Newbie Q - changing TARGETDIR based on mode
Hi. msiexec /i ...msi /quiet TARGETDIR=C:#Temp ? On 10/10/07, Rad Ricka [EMAIL PROTECTED] wrote: Hello, sorry for asking a newbie question; but googling didn't help much. Could somebody please point me to an example that allows specific path for TARGETDIR dir when running msiexec with /quiet switch and offers a different default TARGETDIR path when run interactively? Many thanks, R. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Return Value of RegistrySearch
Hello All,
In following code what would be the value of OLDVERSIONFOPUND.
Actually I want data value of version (Which is 1.07.3) in my case how I can
get that. i have to take decision based on that value.
Property Id=OLDVERSIONFOUND
RegistrySearch Id=OLDVERSION Type=raw Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{7A06128A-B3D8-4125-9C4D-34BFDA05C9FB}
Name=Version
/RegistrySearch
/Property
regards,
Veerendra
-
Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Missing Assembly after Majorupgrade
Hi, I have created an MSI file wich contains a .NET application. The MSI is configured to always do a majorupgrade if an older version is beeing found. The uninstallation is working fine however after the new files are installed I often have the problem that the executable assembly is missing from the directory. After doing a repair the missing executable is installed find. Do you have some hint for me whats wrong? The issue happens only sometimes on different computers and I have no idea what went wrong. Best regards, Sven The Component with Upgradeissues Component Id=TheasoftBinary Guid=12BC8665-443A-43FA-9697-79108F070E64 File Id=Theasoft.exe Name=Theasoft.exe KeyPath=yes Checksum=yes Vital=yes Shortcut Id=TheasoftShortcut Directory=TheasoftShortcutFolder Name=Theasoft WorkingDirectory=BinDir / /File /Component Installsequence InstallExecuteSequence FindRelatedProducts Before=LaunchConditions / RemoveExistingProducts After=InstallValidate / /InstallExecuteSequence _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Missing Assembly after Majorupgrade
If the version of the GAC'ed file has not been incremented between versions then the information at this link is probably describing the situation. http://support.microsoft.com/kb/905238/en-us -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sven Heitmann Sent: Wednesday, October 10, 2007 6:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Missing Assembly after Majorupgrade Hi, I have created an MSI file wich contains a .NET application. The MSI is configured to always do a majorupgrade if an older version is beeing found. The uninstallation is working fine however after the new files are installed I often have the problem that the executable assembly is missing from the directory. After doing a repair the missing executable is installed find. Do you have some hint for me whats wrong? The issue happens only sometimes on different computers and I have no idea what went wrong. Best regards, Sven The Component with Upgradeissues Component Id=TheasoftBinary Guid=12BC8665-443A-43FA-9697-79108F070E64 File Id=Theasoft.exe Name=Theasoft.exe KeyPath=yes Checksum=yes Vital=yes Shortcut Id=TheasoftShortcut Directory=TheasoftShortcutFolder Name=Theasoft WorkingDirectory=BinDir / /File /Component Installsequence InstallExecuteSequence FindRelatedProducts Before=LaunchConditions / RemoveExistingProducts After=InstallValidate / /InstallExecuteSequence _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] QFE authoring after service pack release
Resend ... Appreciate any pointers! Thanks! Ning Hello, So our scenario is this 1) Product RTM'ed (say version 1.0.1000) 2) We created and shipped a service pack 1 (say version 1.0.2000) 3) Now we realize we need to ship a QFE (say version 1.0.2002) So we created a QFE patch that is basically a diff between versions 1.0.1000 and versions 1.0.2002 -- it tries to update 1 file to version 1.0.2002. Now this QFE patch works on a machine that only has the RTM version installed, that 1 binary is updated to version 2002 as expected. On a machine that has SP1 installed, it simply does nothing! On the verbose log, it shows that it's trying to update the file to version 2000, since version 2000 is already on the machine, it does nothing. So my question is, should we author the QFE by diff'ing it to the RTM CD, or diff'ing it to the SP1 CD? Thank you for any input! Ning - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] QFE authoring after service pack release
I believe the last digit of the version is ignored. You might have better luck using 1.0.2020 instead. Just a hunch. Might be worth a try. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ning Lin Sent: Wednesday, October 10, 2007 9:16 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] QFE authoring after service pack release Resend ... Appreciate any pointers! Thanks! Ning Hello, So our scenario is this 1) Product RTM'ed (say version 1.0.1000) 2) We created and shipped a service pack 1 (say version 1.0.2000) 3) Now we realize we need to ship a QFE (say version 1.0.2002) So we created a QFE patch that is basically a diff between versions 1.0.1000 and versions 1.0.2002 -- it tries to update 1 file to version 1.0.2002. Now this QFE patch works on a machine that only has the RTM version installed, that 1 binary is updated to version 2002 as expected. On a machine that has SP1 installed, it simply does nothing! On the verbose log, it shows that it's trying to update the file to version 2000, since version 2000 is already on the machine, it does nothing. So my question is, should we author the QFE by diff'ing it to the RTM CD, or diff'ing it to the SP1 CD? Thank you for any input! Ning - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] NGen and uninstalling
Hi Doug, Can you verify for me whether or not the images are removed after a reboot? My suspicion is that because the file is in use, the OS cant remove it and schedules a Pending File Rename Operation on the file which will be executed on a reboot. If they are not removed on reboot, let me know and I'll dig deeper. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Payne Sent: Tuesday, October 09, 2007 3:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] NGen and uninstalling Hello, I would like some help understanding how the native image element and related custom actions work in Wix 2.0. Specifically, I would like some advice on how to debug a problem I am seeing when uninstalling my product. I am using this element to add assemblies to the Native Image Cache during install, and remove them during uninstall. This works well unless one of the applications relying on these assemblies is running when the product is reinstalled or removed. In that case, even if Restart Manager is able to close the applications, the files sometimes remain in the Native Image folder after uninstall. From the verbose log, I see that the ExecNetFX CA fires, and ngen.exe is indeed called once for each assembly which is to be removed. (Unlike during the installation process, I do not see the actual command line being used for ngen.) I verified: * NetFxScheduleNativeImage is run after InstallValidate. Numerous 2715 errors are logged, indicating the specified file key could not be found in the file table. The second parameter for these messages, the file key itself is either blank or not logged. Regardless, the CA sets the NetFxExecuteNativeImageUninstal and NetFxExecuteNativeImageCommitUninstal propeties. It returns 1 * NetFxExecuteNativeImageCommitUninstall runs next, and returns 1. * NetFxExecuteNativeImageUninstall is skipped. * NetFxExecuteNativeImageCommitInstall runs next, and returns 1. * NetFxExecuteNativeImageInstall is skipped. * The NetFX custom action is then invoked, which appears to run NGen once for each assembly, presumably to uninstall the files from the cache. * The ExecNetFx CA then runs. I don't know what it does, but this is followed in the log by 40 lines of the form RollbackCleanup: File: C:\Config.Msi\4f516.rbf. I also tried using a custom actionw which shuts down the applications before Restart Manager sees them. This is to prevent the user from allowing the applications to run during uninstall. This did not help, as images remained in the cache after setup completed. Has anyone else seen this problem? If so, how did you handle it? Thanks for your time. --Doug - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] QFE authoring after service pack release
The transforms in patches usually only apply to a single baseline. In your case, you chose your RTM as your baseline. A patch can carry multiple transforms but you will need to include both in the patch if you want your patch to apply to both scenarios. The other option is to carry the single transform and set the transform validation bits to say that the transform applies to 1.0.2000 and earlier. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chad Petersen Sent: Wednesday, October 10, 2007 9:26 AM To: Ning Lin; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] QFE authoring after service pack release I believe the last digit of the version is ignored. You might have better luck using 1.0.2020 instead. Just a hunch. Might be worth a try. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ning Lin Sent: Wednesday, October 10, 2007 9:16 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] QFE authoring after service pack release Resend ... Appreciate any pointers! Thanks! Ning Hello, So our scenario is this 1) Product RTM'ed (say version 1.0.1000) 2) We created and shipped a service pack 1 (say version 1.0.2000) 3) Now we realize we need to ship a QFE (say version 1.0.2002) So we created a QFE patch that is basically a diff between versions 1.0.1000 and versions 1.0.2002 -- it tries to update 1 file to version 1.0.2002. Now this QFE patch works on a machine that only has the RTM version installed, that 1 binary is updated to version 2002 as expected. On a machine that has SP1 installed, it simply does nothing! On the verbose log, it shows that it's trying to update the file to version 2000, since version 2000 is already on the machine, it does nothing. So my question is, should we author the QFE by diff'ing it to the RTM CD, or diff'ing it to the SP1 CD? Thank you for any input! Ning - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] NGen and uninstalling
Thanks for your response, Peter, The images are not removed after reboot. I did notice one odd thing, though, after initial install and reboot, THE IMAGES (*.NI.* FILES) WERE IN THE Native Image folder, but ngen reported their status as pending, even though I specified Priority=0 for all the assemblies in the .wxs file. I ran 'ngen update', which fixed this problem, but the images were still not removed from the cache during uninstall if the dependent applications were running. --Doug From: Peter Marcu Sent: Wednesday, October 10, 2007 9:37 AM To: Doug Payne; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Hi Doug, Can you verify for me whether or not the images are removed after a reboot? My suspicion is that because the file is in use, the OS cant remove it and schedules a Pending File Rename Operation on the file which will be executed on a reboot. If they are not removed on reboot, let me know and I'll dig deeper. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Payne Sent: Tuesday, October 09, 2007 3:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] NGen and uninstalling Hello, I would like some help understanding how the native image element and related custom actions work in Wix 2.0. Specifically, I would like some advice on how to debug a problem I am seeing when uninstalling my product. I am using this element to add assemblies to the Native Image Cache during install, and remove them during uninstall. This works well unless one of the applications relying on these assemblies is running when the product is reinstalled or removed. In that case, even if Restart Manager is able to close the applications, the files sometimes remain in the Native Image folder after uninstall. From the verbose log, I see that the ExecNetFX CA fires, and ngen.exe is indeed called once for each assembly which is to be removed. (Unlike during the installation process, I do not see the actual command line being used for ngen.) I verified: * NetFxScheduleNativeImage is run after InstallValidate. Numerous 2715 errors are logged, indicating the specified file key could not be found in the file table. The second parameter for these messages, the file key itself is either blank or not logged. Regardless, the CA sets the NetFxExecuteNativeImageUninstal and NetFxExecuteNativeImageCommitUninstal propeties. It returns 1 * NetFxExecuteNativeImageCommitUninstall runs next, and returns 1. * NetFxExecuteNativeImageUninstall is skipped. * NetFxExecuteNativeImageCommitInstall runs next, and returns 1. * NetFxExecuteNativeImageInstall is skipped. * The NetFX custom action is then invoked, which appears to run NGen once for each assembly, presumably to uninstall the files from the cache. * The ExecNetFx CA then runs. I don't know what it does, but this is followed in the log by 40 lines of the form RollbackCleanup: File: C:\Config.Msi\4f516.rbf. I also tried using a custom actionw which shuts down the applications before Restart Manager sees them. This is to prevent the user from allowing the applications to run during uninstall. This did not help, as images remained in the cache after setup completed. Has anyone else seen this problem? If so, how did you handle it? Thanks for your time. --Doug - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Return Value of RegistrySearch
You should be using the Upgrade table (the WiX upgrade element with
OnlyDetect=Yes) to detect older versions. This will let you create
properties specific to the versions on the system so you can create a
property for a 1.0.7 version.
Phil Wilson
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of V K
Gangwar
Sent: Wednesday, October 10, 2007 5:01 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Return Value of RegistrySearch
Hello All,
In following code what would be the value of OLDVERSIONFOPUND.
Actually I want data value of version (Which is 1.07.3) in my case how
I can get that. i have to take decision based on that value.
Property Id=OLDVERSIONFOUND
RegistrySearch Id=OLDVERSION Type=raw Root=HKLM
Key=SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{7A06128A-B3D8-
4125-9C4D-34BFDA05C9FB} Name=Version
/RegistrySearch
/Property
regards,
Veerendra
Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now
http://us.rd.yahoo.com/evt=48223/*http:/get.games.yahoo.com/proddesc?ga
mekey=monopolyherenow (it's updated for today's economy) at Yahoo!
Games.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] NGen and uninstalling
Ok, I followed up on this and having files left behind after uninstall when an managed app is using it is a known issue with ngen.exe itself. While the images still appear to be there, they will not be loaded so in effect they are deleted from the cache but the file still exists on disk. I know this isn't quite the answer you were hoping for but at least we know its not an installer/CA problem. Its in ngen itself and the way it manages its state. From: Doug Payne Sent: Wednesday, October 10, 2007 10:06 AM To: Peter Marcu; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Thanks for your response, Peter, The images are not removed after reboot. I did notice one odd thing, though, after initial install and reboot, THE IMAGES (*.NI.* FILES) WERE IN THE Native Image folder, but ngen reported their status as pending, even though I specified Priority=0 for all the assemblies in the .wxs file. I ran 'ngen update', which fixed this problem, but the images were still not removed from the cache during uninstall if the dependent applications were running. --Doug From: Peter Marcu Sent: Wednesday, October 10, 2007 9:37 AM To: Doug Payne; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Hi Doug, Can you verify for me whether or not the images are removed after a reboot? My suspicion is that because the file is in use, the OS cant remove it and schedules a Pending File Rename Operation on the file which will be executed on a reboot. If they are not removed on reboot, let me know and I'll dig deeper. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Payne Sent: Tuesday, October 09, 2007 3:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] NGen and uninstalling Hello, I would like some help understanding how the native image element and related custom actions work in Wix 2.0. Specifically, I would like some advice on how to debug a problem I am seeing when uninstalling my product. I am using this element to add assemblies to the Native Image Cache during install, and remove them during uninstall. This works well unless one of the applications relying on these assemblies is running when the product is reinstalled or removed. In that case, even if Restart Manager is able to close the applications, the files sometimes remain in the Native Image folder after uninstall. From the verbose log, I see that the ExecNetFX CA fires, and ngen.exe is indeed called once for each assembly which is to be removed. (Unlike during the installation process, I do not see the actual command line being used for ngen.) I verified: * NetFxScheduleNativeImage is run after InstallValidate. Numerous 2715 errors are logged, indicating the specified file key could not be found in the file table. The second parameter for these messages, the file key itself is either blank or not logged. Regardless, the CA sets the NetFxExecuteNativeImageUninstal and NetFxExecuteNativeImageCommitUninstal propeties. It returns 1 * NetFxExecuteNativeImageCommitUninstall runs next, and returns 1. * NetFxExecuteNativeImageUninstall is skipped. * NetFxExecuteNativeImageCommitInstall runs next, and returns 1. * NetFxExecuteNativeImageInstall is skipped. * The NetFX custom action is then invoked, which appears to run NGen once for each assembly, presumably to uninstall the files from the cache. * The ExecNetFx CA then runs. I don't know what it does, but this is followed in the log by 40 lines of the form RollbackCleanup: File: C:\Config.Msi\4f516.rbf. I also tried using a custom actionw which shuts down the applications before Restart Manager sees them. This is to prevent the user from allowing the applications to run during uninstall. This did not help, as images remained in the cache after setup completed. Has anyone else seen this problem? If so, how did you handle it? Thanks for your time. --Doug - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] NGen and uninstalling
Thanks, Peter. This is consistent with what I just discovered. I paused setup just after my custom action closed down all the running applications, then ran ngen manually on each asembly, in the same order as setup. 'NGen display ...' reported each assembly had been removed, but with one exception, the *.ni.* files were left behind. Did you come across any workarounds during your research? Thanks very much for your assistance! --Doug From: Peter Marcu Sent: Wednesday, October 10, 2007 11:29 AM To: Doug Payne; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Ok, I followed up on this and having files left behind after uninstall when an managed app is using it is a known issue with ngen.exe itself. While the images still appear to be there, they will not be loaded so in effect they are deleted from the cache but the file still exists on disk. I know this isn't quite the answer you were hoping for but at least we know its not an installer/CA problem. Its in ngen itself and the way it manages its state. From: Doug Payne Sent: Wednesday, October 10, 2007 10:06 AM To: Peter Marcu; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Thanks for your response, Peter, The images are not removed after reboot. I did notice one odd thing, though, after initial install and reboot, THE IMAGES (*.NI.* FILES) WERE IN THE Native Image folder, but ngen reported their status as pending, even though I specified Priority=0 for all the assemblies in the .wxs file. I ran 'ngen update', which fixed this problem, but the images were still not removed from the cache during uninstall if the dependent applications were running. --Doug From: Peter Marcu Sent: Wednesday, October 10, 2007 9:37 AM To: Doug Payne; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Hi Doug, Can you verify for me whether or not the images are removed after a reboot? My suspicion is that because the file is in use, the OS cant remove it and schedules a Pending File Rename Operation on the file which will be executed on a reboot. If they are not removed on reboot, let me know and I'll dig deeper. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Payne Sent: Tuesday, October 09, 2007 3:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] NGen and uninstalling Hello, I would like some help understanding how the native image element and related custom actions work in Wix 2.0. Specifically, I would like some advice on how to debug a problem I am seeing when uninstalling my product. I am using this element to add assemblies to the Native Image Cache during install, and remove them during uninstall. This works well unless one of the applications relying on these assemblies is running when the product is reinstalled or removed. In that case, even if Restart Manager is able to close the applications, the files sometimes remain in the Native Image folder after uninstall. From the verbose log, I see that the ExecNetFX CA fires, and ngen.exe is indeed called once for each assembly which is to be removed. (Unlike during the installation process, I do not see the actual command line being used for ngen.) I verified: * NetFxScheduleNativeImage is run after InstallValidate. Numerous 2715 errors are logged, indicating the specified file key could not be found in the file table. The second parameter for these messages, the file key itself is either blank or not logged. Regardless, the CA sets the NetFxExecuteNativeImageUninstal and NetFxExecuteNativeImageCommitUninstal propeties. It returns 1 * NetFxExecuteNativeImageCommitUninstall runs next, and returns 1. * NetFxExecuteNativeImageUninstall is skipped. * NetFxExecuteNativeImageCommitInstall runs next, and returns 1. * NetFxExecuteNativeImageInstall is skipped. * The NetFX custom action is then invoked, which appears to run NGen once for each assembly, presumably to uninstall the files from the cache. * The ExecNetFx CA then runs. I don't know what it does, but this is followed in the log by 40 lines of the form RollbackCleanup: File: C:\Config.Msi\4f516.rbf. I also tried using a custom actionw which shuts down the applications before Restart Manager sees them. This is to prevent the user from allowing the applications to run during uninstall. This did not help, as images remained in the cache after setup completed. Has anyone else seen this problem? If so, how did you handle it? Thanks for your time. --Doug - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net
[WiX-users] install/uninstall on/from custom location does not work on W2K3 but does on Vista
Hi there I have run into an issue where in on W2K3 installing to a custom location does not work. That is, after choosing a custom folder, the install goes through but dumps the contents into the default Program Files folder. Similarly, while uninstalling on W2K3, the msi uninstalls but the bits do not get removed at all. The installation to a custom location and installation from a custom location work fine on vista though. Is this a known issue? If so any workaround? If not, where should I be looking for a change? Here is what my wix directory structure looks like Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLLOCATION ShortName=WinRep Name=$(var.ProductName) ... ... Rachna SDE Repository Modeling Team, CSD Microsoft 425.705.6966 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Cell: 425.533.1626 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] NGen and uninstalling
Sorry, no workarounds that I could see. From: Doug Payne Sent: Wednesday, October 10, 2007 11:50 AM To: Peter Marcu; wix-users@lists.sourceforge.net; Sumit Mehrotra Subject: RE: NGen and uninstalling Thanks, Peter. This is consistent with what I just discovered. I paused setup just after my custom action closed down all the running applications, then ran ngen manually on each asembly, in the same order as setup. 'NGen display ...' reported each assembly had been removed, but with one exception, the *.ni.* files were left behind. Did you come across any workarounds during your research? Thanks very much for your assistance! --Doug From: Peter Marcu Sent: Wednesday, October 10, 2007 11:29 AM To: Doug Payne; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Ok, I followed up on this and having files left behind after uninstall when an managed app is using it is a known issue with ngen.exe itself. While the images still appear to be there, they will not be loaded so in effect they are deleted from the cache but the file still exists on disk. I know this isn't quite the answer you were hoping for but at least we know its not an installer/CA problem. Its in ngen itself and the way it manages its state. From: Doug Payne Sent: Wednesday, October 10, 2007 10:06 AM To: Peter Marcu; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Thanks for your response, Peter, The images are not removed after reboot. I did notice one odd thing, though, after initial install and reboot, THE IMAGES (*.NI.* FILES) WERE IN THE Native Image folder, but ngen reported their status as pending, even though I specified Priority=0 for all the assemblies in the .wxs file. I ran 'ngen update', which fixed this problem, but the images were still not removed from the cache during uninstall if the dependent applications were running. --Doug From: Peter Marcu Sent: Wednesday, October 10, 2007 9:37 AM To: Doug Payne; wix-users@lists.sourceforge.net Subject: RE: NGen and uninstalling Hi Doug, Can you verify for me whether or not the images are removed after a reboot? My suspicion is that because the file is in use, the OS cant remove it and schedules a Pending File Rename Operation on the file which will be executed on a reboot. If they are not removed on reboot, let me know and I'll dig deeper. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Doug Payne Sent: Tuesday, October 09, 2007 3:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] NGen and uninstalling Hello, I would like some help understanding how the native image element and related custom actions work in Wix 2.0. Specifically, I would like some advice on how to debug a problem I am seeing when uninstalling my product. I am using this element to add assemblies to the Native Image Cache during install, and remove them during uninstall. This works well unless one of the applications relying on these assemblies is running when the product is reinstalled or removed. In that case, even if Restart Manager is able to close the applications, the files sometimes remain in the Native Image folder after uninstall. From the verbose log, I see that the ExecNetFX CA fires, and ngen.exe is indeed called once for each assembly which is to be removed. (Unlike during the installation process, I do not see the actual command line being used for ngen.) I verified: * NetFxScheduleNativeImage is run after InstallValidate. Numerous 2715 errors are logged, indicating the specified file key could not be found in the file table. The second parameter for these messages, the file key itself is either blank or not logged. Regardless, the CA sets the NetFxExecuteNativeImageUninstal and NetFxExecuteNativeImageCommitUninstal propeties. It returns 1 * NetFxExecuteNativeImageCommitUninstall runs next, and returns 1. * NetFxExecuteNativeImageUninstall is skipped. * NetFxExecuteNativeImageCommitInstall runs next, and returns 1. * NetFxExecuteNativeImageInstall is skipped. * The NetFX custom action is then invoked, which appears to run NGen once for each assembly, presumably to uninstall the files from the cache. * The ExecNetFx CA then runs. I don't know what it does, but this is followed in the log by 40 lines of the form RollbackCleanup: File: C:\Config.Msi\4f516.rbf. I also tried using a custom actionw which shuts down the applications before Restart Manager sees them. This is to prevent the user from allowing the applications to run during uninstall. This did not help, as images remained in the cache after setup completed. Has anyone else seen this problem? If so, how did you handle it? Thanks for your time. --Doug - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your
[WiX-users] Looking for docs on IIS metabase manipulation in WiX
Is there a source of WiX documentation for all of the fun things you can do to the IIS metabase? Specifically, I'm looking for docs or points or something that gives me a better idea of what I can do natively in WiX what I have to write a custom action to handle, such as detecting if a website exists, stopping it, and then create a new site. Or to figure out what the root directory of that website if it exists? Thanks! Rory - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Maintenance - Change weirdness
DexterSinister wrote: Ok ... [scratching head looking perplexed] ... if none of those properties are being set via command line [since the installer is being invoked via the Change button in Add/Remove Programs] ... is the installer engine scanning the package to get feature names and then checking [in the registry, I'm guessing ...] to see if any of those features are installed ... ? If that's the case, how could you ever change an installation ... ? You wouldn't, so it's a good thing it doesn't work like that.g MSI sets Preselected only in the conditions it's documented to (AFAIK). It doesn't set it because some features are already installed. Something is setting it; if it's not MSI because you're not using the properties in your command line or package, you need to look at the merge modules you're using. First check the .msi's Property table. If that's not it, try taking out the merge modules. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Modifying parameters and sending them to a custom action on a button press
MatPdr wrote: I think I figured out my error. I wasn't putting a 1 in the content of the publish element. See http://msdn2.microsoft.com/en-us/library/aa368037.aspx for details about control events. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Checking User Input and Writing it to a File
0x001A4 wrote: This can be disregarded. The question I am now stuck on is checking for empty values. For instance, in the example below, I got the password check to work, but by default the text boxes are empty and are equal. It is not until something is typed into the first password box that the Next button becomes disabled. How would I check for an empty value? PROPERTY -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Registry permissions are deleted on rollback
Hi, I have a small problem during major upgrade with Registry/Permission element. I have created a very simple example replicating the problem, the sources are below. Steps to recreate: 1. In msi version 1 I create registry key and add some permission to it for NetworkService user. 2. In msi version 2 I update the same registry key and I also have the same permission tag there. Also in this second msi I have a condition which always triggers the rollback (to simulate the problem I have in my real life msi) 3. Install the msi version 1 4. Install the msi version 2 over it - major upgrade - forced rollback 5. After the rollback, the system is not restored to the exact state as it was before installation of the msi version 2. The permissions are deleted! So they are reverted to the state before installation of the msi version 1. -- The first msi source: -- ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Product Id=---- Name=Permission Test Language=1033 Version=2.0.0 UpgradeCode=4086DDFE-9912-425F-835D-0ACD310BD9DE Manufacturer=TestCompany Package Id=---- ShortNames=no InstallerVersion=200 Compressed=yes Manufacturer=TestCompany / Media Id=1 Cabinet=PermissionTest.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Component Id=RegistryComp DiskId=1 Guid=EADA08EB-14F1-44bf-962F-A7FEDB7B8D94 Registry Action=write Type=string Key=SOFTWARE\PermissionTest Name=Test Value=2.0.0 Root=HKLM Permission GenericAll='yes' EnumerateSubkeys='yes' CreateSubkeys='yes' Extended='yes' User='NetworkService' / /Registry /Component /Directory Upgrade Id=4086DDFE-9912-425F-835D-0ACD310BD9DE UpgradeVersion OnlyDetect=no Property=UPGRADE IncludeMinimum=yes IncludeMaximum=no MigrateFeatures=yes IgnoreRemoveFailure=no Minimum=1.0.0 Maximum=2.0.0 / /Upgrade !-- Sequence of install actions -- InstallExecuteSequence RemoveExistingProducts After=InstallInitialize UPGRADE/RemoveExistingProducts /InstallExecuteSequence Feature Id=Complete Title=PermissionTest Level=1 TypicalDefault=install Absent=disallow AllowAdvertise=no ComponentRef Id=RegistryComp/ /Feature Property Id='ALLUSERS' Value='1' / /Product /Wix -- The second msi source: -- ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Product Id=---- Name=Permission Test Language=1033 Version=2.0.1 UpgradeCode=4086DDFE-9912-425F-835D-0ACD310BD9DE Manufacturer=TestCompany Package Id=---- ShortNames=no InstallerVersion=200 Compressed=yes Manufacturer=TestCompany / Media Id=1 Cabinet=PermissionTest.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Component Id=RegistryComp DiskId=1 Guid=EADA08EB-14F1-44bf-962F-A7FEDB7B8D94 Registry Action=write Type=string Key=SOFTWARE\PermissionTest Name=Test Value=2.0.1 Root=HKLM Permission GenericAll='yes' EnumerateSubkeys='yes' CreateSubkeys='yes' Extended='yes' User='NetworkService' / /Registry /Component /Directory Upgrade Id=4086DDFE-9912-425F-835D-0ACD310BD9DE UpgradeVersion OnlyDetect=no Property=UPGRADE IncludeMinimum=yes IncludeMaximum=no MigrateFeatures=yes IgnoreRemoveFailure=no Minimum=1.0.0 Maximum=2.0.1 / /Upgrade CustomAction Id='ForceRollback' Error='Forced Rollback' / !-- Sequence of install actions -- InstallExecuteSequence RemoveExistingProducts After=InstallInitialize UPGRADE/RemoveExistingProducts Custom Action=ForceRollback Sequence=40011/Custom /InstallExecuteSequence Feature Id=Complete Title=PermissionTest Level=1 TypicalDefault=install Absent=disallow AllowAdvertise=no ComponentRef Id=RegistryComp/ /Feature Property Id='ALLUSERS' Value='1' / /Product /Wix -- Any ideas how to avoid this? Is it a bug? I have also tried it in Wix 3.0.3221 with the same result (using the UtilExtension) Thanks Jan Brabec Radiant Systems - This SF.net email is sponsored by: Splunk Inc. Still grepping
