[WiX-users] How would people handle this situation
Hi: I have a situation when by I am writing an msi for a product which currently uses a non-windows installer based installation method. Wha I want to acomplish is the following: do a registry search for the uninstallation executable, if the exe is found run it. I can accomplish the first part (registry search), but I need the custom action to come before any ui dialogues. Wher should I sequence this ca? Any help apreciated. Sean. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How do you skip overwriting existing registry value
My installer writes default values to the registry for a new install However, I'd like the installer to skip writing if it already exists as they are user created - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Always replace file
Hi all, How can I get an install to always replace an existing file on a maintenance change or repair option? The file is a config file not a binary with versioning. Regards, /James * This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS. To protect the environment please do not print this e-mail unless necessary. NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00 ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Changing a registry key
Hi all, as part of my install I have a custom dialog that sets a value. I need to keep this value after the product is uninstalled or changed so that subsequent installs can pick up the previous settings. I currently have the following: Component Id=InstallRegistry Guid=xxx Permanent=yes RegistryKey Root=HKCU Key=Software\myco\myprod Action=create RegistryValue Type=string Name=key1 Value=[PROXY_URL] Action=write/ RegistryValue Type=string Name=key2 Value=[PROXY_URL_CUSTOM] Action=write/ /RegistryKey inside the install directory section and reference it in the feature. This works as on a uninstall the key gets removed but subsequent installs or changes to the current install do not update the registry with the new values from the variables. Obviously I meant to say on uninstall the gey remains but... How can I acheive this? Regards, /James * This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS. To protect the environment please do not print this e-mail unless necessary. NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00 ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Changing a registry key
Hi all, as part of my install I have a custom dialog that sets a value. I need to keep this value after the product is uninstalled or changed so that subsequent installs can pick up the previous settings. I currently have the following: Component Id=InstallRegistry Guid=xxx Permanent=yes RegistryKey Root=HKCU Key=Software\myco\myprod Action=create RegistryValue Type=string Name=key1 Value=[PROXY_URL] Action=write/ RegistryValue Type=string Name=key2 Value=[PROXY_URL_CUSTOM] Action=write/ /RegistryKey inside the install directory section and reference it in the feature. This works as on a uninstall the key gets removed but subsequent installs or changes to the current install do not update the registry with the new values from the variables. How can I acheive this? Regards, /James * This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS. To protect the environment please do not print this e-mail unless necessary. NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00 ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Always replace file
Again, read about KeyPath and file versioning in the MSI SDK. -Original Message- From: Nord, James [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 03:00 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Always replace file Hi all, How can I get an install to always replace an existing file on a maintenance change or repair option? The file is a config file not a binary with versioning. Regards, /James * This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS. To protect the environment please do not print this e-mail unless necessary. NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00 ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How do you skip overwriting existing registry value
Read about KeyPaths for Components in the MSI SDK. You'll see how to control the install behavior of the Component. -Original Message- From: Yu, Brian [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 02:55 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How do you skip overwriting existing registry value My installer writes default values to the registry for a new install However, I'd like the installer to skip writing if it already exists as they are user created - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Changing a registry key
Read about how the KeyPath affects the Component install state. If you look in a verbose log file, I expect you'll see your Componentisn't getting installed a second time because the Component thinks it is already installed. -Original Message- From: Nord, James [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 02:58 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Changing a registry key Hi all, as part of my install I have a custom dialog that sets a value. I need to keep this value after the product is uninstalled or changed so that subsequent installs can pick up the previous settings. I currently have the following: Component Id=InstallRegistry Guid=xxx Permanent=yes RegistryKey Root=HKCU Key=Software\myco\myprod Action=create RegistryValue Type=string Name=key1 Value=[PROXY_URL] Action=write/ RegistryValue Type=string Name=key2 Value=[PROXY_URL_CUSTOM] Action=write/ /RegistryKey inside the install directory section and reference it in the feature. This works as on a uninstall the key gets removed but subsequent installs or changes to the current install do not update the registry with the new values from the variables. How can I acheive this? Regards, /James * This e-mail is confidential, the property of NDS Ltd and intended for the addressee only. Any dissemination, copying or distribution of this message or any attachments by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. Messages sent to and from NDS may be monitored. NDS cannot guarantee any message delivery method is secure or error-free. Information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept responsibility for any errors or omissions in this message and/or attachment that arise as a result of transmission. You should carry out your own virus checks before opening any attachment. Any views or opinions presented are solely those of the author and do not necessarily represent those of NDS. To protect the environment please do not print this e-mail unless necessary. NDS Limited Registered office: One Heathrow Boulevard, 286 Bath Road, West Drayton, Middlesex, UB7 0DQ, United Kingdom. A company registered in England and Wales Registered no. 3080780 VAT no. GB 603 8808 40-00 ** - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] elevating twice
You'd have to launch your configuration tool as a deferred async CustomAction. -Original Message- From: Calin Iaru [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 06:54 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] elevating twice If UAC is enabled, then my MSI will require one elevation prompt during installation. This is acceptable, since registry keys are written and other components such as drivers are installed. What I would like to do is to circumvent a second elevation when the MSI file is scheduled to launch an image at the end of the installation. Here's the use case: - the user installs a feature that requires configuration - the configuration tool is launched at the end of the installation if the user marks that option - the configuration tool needs to write files in the system directory If CreateProcess is called in the custom action, then the installer will fail to launch due to insufficient privileges. If ShellExecute is called, then the process can be launched only if the user confirms a second UAC. My question is: can I bypass this second elevation and make the process run from the context of the first elevation - ie. the context of the msiexec process that is running with elevated installation privileges? I expect not since that msiexec or dllhost has a limited scope. The setup uses version 2.0.4820.0 of WiX. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How would people handle this situation
After CostFinalize? -Original Message- From: Sean Farrow [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 00:08 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How would people handle this situation Hi: I have a situation when by I am writing an msi for a product which currently uses a non-windows installer based installation method. Wha I want to acomplish is the following: do a registry search for the uninstallation executable, if the exe is found run it. I can accomplish the first part (registry search), but I need the custom action to come before any ui dialogues. Wher should I sequence this ca? Any help apreciated. Sean. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Scheduling a Reboot After InstallFinalize
I think the problem is that I'm trying to perform this action in a Merge Module. I have a merge module that installs some underlying driver files and needs a reboot. The code you mentioned below does work for a MSI but not a MSM which according to Microsoft shouldn't anyway. I am currently doing the following: InstallExecuteSequence ScheduleReboot Sequence=7000 / InstallFinalize Sequence=6600 / /InstallExecuteSequence This works but I guess I'm just worried about anybody that might pull in my MSM who has modified the sequence number for InstallFinalize to be greater than the number I hard-coded in. Thanks Rob Mensching-2 wrote: InstallExecuteSequence ScheduleReboot After=InstallFinalize / /InstallExecuteSequence Works for me. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 08:10 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Scheduling a Reboot After InstallFinalize I'm trying to convert some old Wise code over to WiX and ran into a problem where I need to invoke the ScheduleReboot action after InstallFinalize. According to WiX and Microsoft, you can't use the BaseAction column when using standard actions which is what I need to do. I always want ScheduleReboot to occur after InstallFinalize. I found an earlier forum http://n2.nabble.com/Reboot-at-end-td688131.html post which mentioned that you should be using the Before and After attributes of ScheduleReboot but WiX v3 gives you an error saying that InstallExecuteSequence table contains a standard action 'ScheduleReboot' that does not have a sequence number specified. The Sequence attribute is required for standard actions in a merge module. Please remove the action or use the Sequence attribute. So my question is, how can I ensure that ScheduleReboot will always happen after InstallFinalize? I can use the Sequence attribute, but I would rather no hard-code this value. Thanks -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599287.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599571.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Scheduling a Reboot After InstallFinalize
Oh, Merge Module, well that changes everything. Yeah, MSI SDK doesn't allow that. Why are you using a Merge Module? Very unfriendly of a Merge Module to shove a reboot into someone else's product... especially if they already have a ScheduleReboot elsewhere. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 09:09 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Scheduling a Reboot After InstallFinalize I think the problem is that I'm trying to perform this action in a Merge Module. I have a merge module that installs some underlying driver files and needs a reboot. The code you mentioned below does work for a MSI but not a MSM which according to Microsoft shouldn't anyway. I am currently doing the following: InstallExecuteSequence ScheduleReboot Sequence=7000 / InstallFinalize Sequence=6600 / /InstallExecuteSequence This works but I guess I'm just worried about anybody that might pull in my MSM who has modified the sequence number for InstallFinalize to be greater than the number I hard-coded in. Thanks Rob Mensching-2 wrote: InstallExecuteSequence ScheduleReboot After=InstallFinalize / /InstallExecuteSequence Works for me. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 08:10 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Scheduling a Reboot After InstallFinalize I'm trying to convert some old Wise code over to WiX and ran into a problem where I need to invoke the ScheduleReboot action after InstallFinalize. According to WiX and Microsoft, you can't use the BaseAction column when using standard actions which is what I need to do. I always want ScheduleReboot to occur after InstallFinalize. I found an earlier forum http://n2.nabble.com/Reboot-at-end-td688131.html post which mentioned that you should be using the Before and After attributes of ScheduleReboot but WiX v3 gives you an error saying that InstallExecuteSequence table contains a standard action 'ScheduleReboot' that does not have a sequence number specified. The Sequence attribute is required for standard actions in a merge module. Please remove the action or use the Sequence attribute. So my question is, how can I ensure that ScheduleReboot will always happen after InstallFinalize? I can use the Sequence attribute, but I would rather no hard-code this value. Thanks -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599287.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599571.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Scheduling a Reboot After InstallFinalize
This MSM is currently shared by not only the product I create, but also by a few other products internally. I inherited this code from another developer and I'm willing to try different routes to conform to better practice. I thought that if an MSI and MSM both defined some standard action with different sequence numbers, the MSI always overruled. Maybe not? The overall scenario is that this MSM installs underlying driver files and needs a reboot at the end of the installation. This MSM is shared by internal groups and we allow our customers to pull in this MSM as well (i.e. maybe if they were building some MSI in Visual Studio) If you have some thoughts regarding a different way to handle this scenario, I'm up for anything. Thanks Rob Mensching-2 wrote: Oh, Merge Module, well that changes everything. Yeah, MSI SDK doesn't allow that. Why are you using a Merge Module? Very unfriendly of a Merge Module to shove a reboot into someone else's product... especially if they already have a ScheduleReboot elsewhere. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 09:09 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Scheduling a Reboot After InstallFinalize I think the problem is that I'm trying to perform this action in a Merge Module. I have a merge module that installs some underlying driver files and needs a reboot. The code you mentioned below does work for a MSI but not a MSM which according to Microsoft shouldn't anyway. I am currently doing the following: InstallExecuteSequence ScheduleReboot Sequence=7000 / InstallFinalize Sequence=6600 / /InstallExecuteSequence This works but I guess I'm just worried about anybody that might pull in my MSM who has modified the sequence number for InstallFinalize to be greater than the number I hard-coded in. Thanks Rob Mensching-2 wrote: InstallExecuteSequence ScheduleReboot After=InstallFinalize / /InstallExecuteSequence Works for me. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 08:10 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Scheduling a Reboot After InstallFinalize I'm trying to convert some old Wise code over to WiX and ran into a problem where I need to invoke the ScheduleReboot action after InstallFinalize. According to WiX and Microsoft, you can't use the BaseAction column when using standard actions which is what I need to do. I always want ScheduleReboot to occur after InstallFinalize. I found an earlier forum http://n2.nabble.com/Reboot-at-end-td688131.html post which mentioned that you should be using the Before and After attributes of ScheduleReboot but WiX v3 gives you an error saying that InstallExecuteSequence table contains a standard action 'ScheduleReboot' that does not have a sequence number specified. The Sequence attribute is required for standard actions in a merge module. Please remove the action or use the Sequence attribute. So my question is, how can I ensure that ScheduleReboot will always happen after InstallFinalize? I can use the Sequence attribute, but I would rather no hard-code this value. Thanks -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599287.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599571.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for
Re: [WiX-users] Scheduling a Reboot After InstallFinalize
1. Fair enough. Sharing with multiple products (not all using WiX toolset) pretty much requires Merge Modules. 2. Ahh, yeah, that sounds right. MSI overrides MSM sequencing. I've avoided MSMs for quite a while moving to .wixlibs... but all my products use WiX so I can do that. 3. Drivers suck. smile/ If the reboot is really required then you're stuck. Again, drivers suck. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 09:21 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Scheduling a Reboot After InstallFinalize This MSM is currently shared by not only the product I create, but also by a few other products internally. I inherited this code from another developer and I'm willing to try different routes to conform to better practice. I thought that if an MSI and MSM both defined some standard action with different sequence numbers, the MSI always overruled. Maybe not? The overall scenario is that this MSM installs underlying driver files and needs a reboot at the end of the installation. This MSM is shared by internal groups and we allow our customers to pull in this MSM as well (i.e. maybe if they were building some MSI in Visual Studio) If you have some thoughts regarding a different way to handle this scenario, I'm up for anything. Thanks Rob Mensching-2 wrote: Oh, Merge Module, well that changes everything. Yeah, MSI SDK doesn't allow that. Why are you using a Merge Module? Very unfriendly of a Merge Module to shove a reboot into someone else's product... especially if they already have a ScheduleReboot elsewhere. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 09:09 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Scheduling a Reboot After InstallFinalize I think the problem is that I'm trying to perform this action in a Merge Module. I have a merge module that installs some underlying driver files and needs a reboot. The code you mentioned below does work for a MSI but not a MSM which according to Microsoft shouldn't anyway. I am currently doing the following: InstallExecuteSequence ScheduleReboot Sequence=7000 / InstallFinalize Sequence=6600 / /InstallExecuteSequence This works but I guess I'm just worried about anybody that might pull in my MSM who has modified the sequence number for InstallFinalize to be greater than the number I hard-coded in. Thanks Rob Mensching-2 wrote: InstallExecuteSequence ScheduleReboot After=InstallFinalize / /InstallExecuteSequence Works for me. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 08:10 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Scheduling a Reboot After InstallFinalize I'm trying to convert some old Wise code over to WiX and ran into a problem where I need to invoke the ScheduleReboot action after InstallFinalize. According to WiX and Microsoft, you can't use the BaseAction column when using standard actions which is what I need to do. I always want ScheduleReboot to occur after InstallFinalize. I found an earlier forum http://n2.nabble.com/Reboot-at-end-td688131.html post which mentioned that you should be using the Before and After attributes of ScheduleReboot but WiX v3 gives you an error saying that InstallExecuteSequence table contains a standard action 'ScheduleReboot' that does not have a sequence number specified. The Sequence attribute is required for standard actions in a merge module. Please remove the action or use the Sequence attribute. So my question is, how can I ensure that ScheduleReboot will always happen after InstallFinalize? I can use the Sequence attribute, but I would rather no hard-code this value. Thanks -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599287.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/
Re: [WiX-users] Scheduling a Reboot After InstallFinalize
The sequencing of ScheduleReboot isn't usually very important - you can put it anywhere, and it just sets a flag to prompt for a reboot after the install. The action itself doesn't need to be after InstallFinalize. It's the ForceReboot action that is immediate. Phil Wilson -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 9:09 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Scheduling a Reboot After InstallFinalize I think the problem is that I'm trying to perform this action in a Merge Module. I have a merge module that installs some underlying driver files and needs a reboot. The code you mentioned below does work for a MSI but not a MSM which according to Microsoft shouldn't anyway. I am currently doing the following: InstallExecuteSequence ScheduleReboot Sequence=7000 / InstallFinalize Sequence=6600 / /InstallExecuteSequence This works but I guess I'm just worried about anybody that might pull in my MSM who has modified the sequence number for InstallFinalize to be greater than the number I hard-coded in. Thanks Rob Mensching-2 wrote: InstallExecuteSequence ScheduleReboot After=InstallFinalize / /InstallExecuteSequence Works for me. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 08:10 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Scheduling a Reboot After InstallFinalize I'm trying to convert some old Wise code over to WiX and ran into a problem where I need to invoke the ScheduleReboot action after InstallFinalize. According to WiX and Microsoft, you can't use the BaseAction column when using standard actions which is what I need to do. I always want ScheduleReboot to occur after InstallFinalize. I found an earlier forum http://n2.nabble.com/Reboot-at-end-td688131.html post which mentioned that you should be using the Before and After attributes of ScheduleReboot but WiX v3 gives you an error saying that InstallExecuteSequence table contains a standard action 'ScheduleReboot' that does not have a sequence number specified. The Sequence attribute is required for standard actions in a merge module. Please remove the action or use the Sequence attribute. So my question is, how can I ensure that ScheduleReboot will always happen after InstallFinalize? I can use the Sequence attribute, but I would rather no hard-code this value. Thanks -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599287.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599571.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] Scheduling a Reboot After InstallFinalize
Thanks guys, appreciate the help. -Jonathan Wilson, Phil wrote: The sequencing of ScheduleReboot isn't usually very important - you can put it anywhere, and it just sets a flag to prompt for a reboot after the install. The action itself doesn't need to be after InstallFinalize. It's the ForceReboot action that is immediate. Phil Wilson -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 9:09 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Scheduling a Reboot After InstallFinalize I think the problem is that I'm trying to perform this action in a Merge Module. I have a merge module that installs some underlying driver files and needs a reboot. The code you mentioned below does work for a MSI but not a MSM which according to Microsoft shouldn't anyway. I am currently doing the following: InstallExecuteSequence ScheduleReboot Sequence=7000 / InstallFinalize Sequence=6600 / /InstallExecuteSequence This works but I guess I'm just worried about anybody that might pull in my MSM who has modified the sequence number for InstallFinalize to be greater than the number I hard-coded in. Thanks Rob Mensching-2 wrote: InstallExecuteSequence ScheduleReboot After=InstallFinalize / /InstallExecuteSequence Works for me. -Original Message- From: jnewton [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 08:10 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Scheduling a Reboot After InstallFinalize I'm trying to convert some old Wise code over to WiX and ran into a problem where I need to invoke the ScheduleReboot action after InstallFinalize. According to WiX and Microsoft, you can't use the BaseAction column when using standard actions which is what I need to do. I always want ScheduleReboot to occur after InstallFinalize. I found an earlier forum http://n2.nabble.com/Reboot-at-end-td688131.html post which mentioned that you should be using the Before and After attributes of ScheduleReboot but WiX v3 gives you an error saying that InstallExecuteSequence table contains a standard action 'ScheduleReboot' that does not have a sequence number specified. The Sequence attribute is required for standard actions in a merge module. Please remove the action or use the Sequence attribute. So my question is, how can I ensure that ScheduleReboot will always happen after InstallFinalize? I can use the Sequence attribute, but I would rather no hard-code this value. Thanks -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599287.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/Scheduling-a-Reboot-After-InstallFinalize-tp1599287p1599571.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/
Re: [WiX-users] Install Localisation
Having worked through a few bugs in light I am now back to looking at this problem again. What I would like to do is create an MSI with a separate transform (MST) for each language. So the process I intend to use is: 1. Create wixout for my install using the -sloc parameter. 2. Link the wixout to create the English MSI. 3. For each language run light on the wixout to create a new translated MSI or wixout. 4. Use torch to create an MST for each language from 3. Until the next WiX release I am not able to try this but I can see a couple of problems: 1. The documentation for torch says that if you use a wixout input file it will only create a wixout (-xo set by default if -xi set). Is this correct? If it is, how do you create an MST from a wixout? 2. Every time I run light it will create a new product code but I don't want that, I want one product code and simply install with a different UI language. From what I have read this seems to be a valid approach. Can anyone suggest how I can do this? 3. I thought I could solve 2 but editing the wixout file and putting in my own ProductCode so that it is not regenerated but it appears to start with some binary data. I think that it is always binding the files into wixout not just when -bf is used. Does this sound like a bug? Thanks for your help Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 06 November 2008 22:31 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 0. *Every* MSI should have a different PackageCode. Even two builds of the same MSI. 1. You *can* have different ProductCodes for all of your languages. Depends on what your SxS story is. 2. The most efficient way I've seen this done is: a. Link to .wixout files. This will get you everything but the final localized build. b. Use cab cache to minimize the number of cabinets rebuilt. If you are really careful with your Media elements this can lead to huge savings. c. Link the .wixout file with each .wxl file in turn, to build the final MSI files. d. Use torch to build transforms from all of the MSIs. There may be an optimization where you can build .wixouts with .wxl files to create localized .wixouts and torch those .wixouts. This will not have the file table information correct so it may not work for you. Also, Peter was talking about issues with torch and .wixouts but I don't remember them right now. It's been a long while since I did all the above so YMMV and please feel free to correct me where I'm wrong. It might be a bug. smile/ -Original Message- From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2008 14:19 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Install Localisation I am looking for advise in localising installs. I need to deploy an application in several languages and I thought I had the solution, what I did was this: 1. Set the CAB file as not embedded as the files are the same for all languages. 2. Run candle for wxs files 3. Run light against the wixobj files but specifying a different culture each time I ran it 4. This creates an msi for each language with an external CAB file. This works but I have just noticed a major problem, each time I run light it generates a new product and package code (I use the Guid=* syntax for them). So this means that each language has a different product/package code and this is clear not really correct. Can anyone suggest a better method for doing this? Ideally I would like to generate one msi and then run some command to generate a transform for each language. Thanks Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net
Re: [WiX-users] App~Search query
In article [EMAIL PROTECTED], Sean Farrow [EMAIL PROTECTED] writes: I am in the process of coding a msi. I need to search for multiple applications and only display a message and about the installation if none of the applications are found. Am I better off using an AppSearch element or using a custom action and settings properties? Use AppSearch to set one property for each application you're searching for, say APP1FOUND, APP2FOUND, etc. Then in LaunchConditions combine the properties together so that the requirement message fires if none of them are found: NOT (APP1FOUND OR ... OR APP2FOUND) -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Show/Hide Textbox on event of DropDown
In article [EMAIL PROTECTED], sujanakar reddy [EMAIL PROTECTED] writes: In my installer (using WiX 3.0) I am displaying a list of items in ComboBox c ontrol and providing a value of Create New in my dropdown so that if the user chooses the Create New item, I want to show textbox below the dropdown scree n in same dialog. Is it possible in WiX? Don't put it in the combo box, just put a button there marked New... and use it to spawn a modal dialog. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] cannot find VCProjectEngine (again, ignore the previous one if it went through)
Thanks for the reply. I guess you misunderstood my question - I am using VC2008 and .Net Framework 3.5, but when I build I got error message about missing VCProjectEngine and suggest to install VC2005 and .Net Framework 2.0. *** Here is message: C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.0\Wix.targets(0,0): warning MSB3421: Could not load the Visual C++ component Microsoft.VisualStudio.VCProjectEngine, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. To fix this, 1) install the .NET Framework 2.0 SDK or 2) install Microsoft Visual Studio 2005. Could not load file or assembly 'Microsoft.VisualStudio.VCProjectEngine, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. *** Here is my original email: I got this warning when build the Wix project which was created by using Visual Studio 2008 and .Net Framework 3.5. It is looking for VCProjectEngine and Visual Studio 2005. C:\Program Files (x86)\MSBuild\Microsoft\WiX\v3.0\Wix.targets(0,0): warning MSB3421: Could not load the Visual C++ component Microsoft.VisualStudio.VCProjectEngine, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. To fix this, 1) install the .NET Framework 2.0 SDK or 2) install Microsoft Visual Studio 2005. Could not load file or assembly 'Microsoft.VisualStudio.VCProjectEngine, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. As I mentioned, the Wix project is created in VS2008, and my Framework version is 3.5. Does anyone know where is wrong for getting this warning? By the way, I am using Wix 3.0.4513. -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: November 29, 2008 9:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cannot find VCProjectEngine (again, ignore the previous one if it went through) Jason Ding wrote: I got this warning when build the Wix project which was created by using Visual Studio 2008 and .Net Framework 3.5. It is looking for VCProjectEngine and Visual Studio 2005. Are you trying to refer to project variables from a VS2008 .vcproj? If so, that's not supported (yet); doing so creates a dependency on .NET 3.5, which we don't otherwise require. By the way, I am using Wix 3.0.4513. I'd suggest trying this with the latest weekly build from http://wix.sourceforge.net/releases/. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Detecting previous installs
In our past releases we had a version 2.5.7.1 installer and a version 2.5.7.9 installer. Now a newer installer needs to detect the 2.5.7.9, but it ignores the final fourth digit and if they have the 2.5.7.1 only installed then the LaunchCondition is ignored. Any other way to tell if 2.5.7.9 is installed without confusing it with 2.5.7.1? Thanks Chad - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Detecting previous installs
Nope, that's the Windows Installer behavior. -Original Message- From: Chad Petersen [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 10:41 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Detecting previous installs In our past releases we had a version 2.5.7.1 installer and a version 2.5.7.9 installer. Now a newer installer needs to detect the 2.5.7.9, but it ignores the final fourth digit and if they have the 2.5.7.1 only installed then the LaunchCondition is ignored. Any other way to tell if 2.5.7.9 is installed without confusing it with 2.5.7.1? Thanks Chad - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] any tips on why the following xmlfile machine.config install changes are not working
Any tips on why the following xmlfile machine.config install changes are not working? I'm using the following component entries: util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot; Action=createElement / util:XmlConfig Id=RemoveBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions VerifyPath=/configuration/system.serviceModel/extensions/behaviorExtensions/[EMAIL PROTECTED]quot;enableBizTalkHeaderInspectorquot; amp;amp; @type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;[\]] Action=delete Node=element On=uninstall / To try and get this new add / element created during install but finding that no machine.config changes exist after setup completes. configuration system.serviceModel extensions behaviorExtensions . . . . . . add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94 / /behaviorExtensions The verbose logs show the following ExecXmlFile property setting and execution of a similarly named custom action Property(S): ExecXmlFile = 2EUR0EURC:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.configEUR5EUR0EUR/configuration/system.serviceModel/extensions/behaviorExtensionsEURaddEURname=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Prevent RemoveFolder actions during an upgrade
Hey all, My installer uses RemoveExistingProducts to uninstall any previous versions of my application during an install, which is working fine for the most part. However, one of my components contains of a bunch of registry settings that I clean up on uninstall. I'm currently achieving this by including a RemoveFolder in that component which seems to clean everything up correctly on uninstall. Unfortunately, it's also blowing away my registry folder on upgrades as well. Is there any way I can prevent that RemoveFolder from getting triggered during an upgrade? Cheers, Colin - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install Localisation
2. Is there any scope for making this optional or replacing Product/@Id=* on the first pass of light? The PackageCode is not regenerated on every run of light, is this not the same? I can't find any good documentation on Windows Installer localisation, do you think I am doing the right thing to localise my install or is it my approach that is floored. Thanks Neil -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 20:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 1. Don't know. 2. If you use Product/@Id=* then it always generates a new ProductCode. If you don't want that, don't use *. 3. No. There are cases where you'll end up with a binary .wixout even if you don't use -bf, especially around the use of CustomActions. -Original Message- From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 10:34 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation Having worked through a few bugs in light I am now back to looking at this problem again. What I would like to do is create an MSI with a separate transform (MST) for each language. So the process I intend to use is: 1. Create wixout for my install using the -sloc parameter. 2. Link the wixout to create the English MSI. 3. For each language run light on the wixout to create a new translated MSI or wixout. 4. Use torch to create an MST for each language from 3. Until the next WiX release I am not able to try this but I can see a couple of problems: 1. The documentation for torch says that if you use a wixout input file it will only create a wixout (-xo set by default if -xi set). Is this correct? If it is, how do you create an MST from a wixout? 2. Every time I run light it will create a new product code but I don't want that, I want one product code and simply install with a different UI language. From what I have read this seems to be a valid approach. Can anyone suggest how I can do this? 3. I thought I could solve 2 but editing the wixout file and putting in my own ProductCode so that it is not regenerated but it appears to start with some binary data. I think that it is always binding the files into wixout not just when -bf is used. Does this sound like a bug? Thanks for your help Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 06 November 2008 22:31 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 0. *Every* MSI should have a different PackageCode. Even two builds of the same MSI. 1. You *can* have different ProductCodes for all of your languages. Depends on what your SxS story is. 2. The most efficient way I've seen this done is: a. Link to .wixout files. This will get you everything but the final localized build. b. Use cab cache to minimize the number of cabinets rebuilt. If you are really careful with your Media elements this can lead to huge savings. c. Link the .wixout file with each .wxl file in turn, to build the final MSI files. d. Use torch to build transforms from all of the MSIs. There may be an optimization where you can build .wixouts with .wxl files to create localized .wixouts and torch those .wixouts. This will not have the file table information correct so it may not work for you. Also, Peter was talking about issues with torch and .wixouts but I don't remember them right now. It's been a long while since I did all the above so YMMV and please feel free to correct me where I'm wrong. It might be a bug. smile/ -Original Message- From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2008 14:19 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Install Localisation I am looking for advise in localising installs. I need to deploy an application in several languages and I thought I had the solution, what I did was this: 1. Set the CAB file as not embedded as the files are the same for all languages. 2. Run candle for wxs files 3. Run light against the wixobj files but specifying a different culture each time I ran it 4. This creates an msi for each language with an external CAB file. This works but I have just noticed a major problem, each time I run light it generates a new product and package code (I use the Guid=* syntax for them). So this means that each language has a different product/package code and this is clear not really correct. Can anyone suggest a better method for doing this? Ideally I would like to generate one msi and then run some command to generate a transform for each language. Thanks Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: [WiX-users] Install Localisation
I guess it is laziness on my part :-) I am just going to have to write some code. I just strikes me as a common requirement to generate a transform without a different ProductCode - I guess that makes it a feature request. May be it should be a torch change rather than light. I'll look at that package code issue and see what I can find. Neil -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 22:08 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 2. The PackageCode should be regenerated with every run of light. If not, that would be a bad bug. There is no scope like you are asking for. IMHO, if you want to manage your ProductCode then you should manage your ProductCode. You could open a feature request if you want. Nothing in you scenario is completely unexpected. Generating transforms is complete supported. You'll need something to apply the transforms at run time, presumably. The bugs in the WiX toolset are being fixed, BTW. -Original Message- From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 13:59 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 2. Is there any scope for making this optional or replacing Product/@Id=* on the first pass of light? The PackageCode is not regenerated on every run of light, is this not the same? I can't find any good documentation on Windows Installer localisation, do you think I am doing the right thing to localise my install or is it my approach that is floored. Thanks Neil -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 20:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 1. Don't know. 2. If you use Product/@Id=* then it always generates a new ProductCode. If you don't want that, don't use *. 3. No. There are cases where you'll end up with a binary .wixout even if you don't use -bf, especially around the use of CustomActions. -Original Message- From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 10:34 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation Having worked through a few bugs in light I am now back to looking at this problem again. What I would like to do is create an MSI with a separate transform (MST) for each language. So the process I intend to use is: 1. Create wixout for my install using the -sloc parameter. 2. Link the wixout to create the English MSI. 3. For each language run light on the wixout to create a new translated MSI or wixout. 4. Use torch to create an MST for each language from 3. Until the next WiX release I am not able to try this but I can see a couple of problems: 1. The documentation for torch says that if you use a wixout input file it will only create a wixout (-xo set by default if -xi set). Is this correct? If it is, how do you create an MST from a wixout? 2. Every time I run light it will create a new product code but I don't want that, I want one product code and simply install with a different UI language. From what I have read this seems to be a valid approach. Can anyone suggest how I can do this? 3. I thought I could solve 2 but editing the wixout file and putting in my own ProductCode so that it is not regenerated but it appears to start with some binary data. I think that it is always binding the files into wixout not just when -bf is used. Does this sound like a bug? Thanks for your help Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 06 November 2008 22:31 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 0. *Every* MSI should have a different PackageCode. Even two builds of the same MSI. 1. You *can* have different ProductCodes for all of your languages. Depends on what your SxS story is. 2. The most efficient way I've seen this done is: a. Link to .wixout files. This will get you everything but the final localized build. b. Use cab cache to minimize the number of cabinets rebuilt. If you are really careful with your Media elements this can lead to huge savings. c. Link the .wixout file with each .wxl file in turn, to build the final MSI files. d. Use torch to build transforms from all of the MSIs. There may be an optimization where you can build .wixouts with .wxl files to create localized .wixouts and torch those .wixouts. This will not have the file table information correct so it may not work for you. Also, Peter was talking about issues with torch and .wixouts but I don't remember them right now. It's been a long while since I did all the above so YMMV and please feel free to correct me where I'm wrong. It might be a bug. smile/
[WiX-users] Permanent Component being removed on uninstall
Trying to create a registry key which is edited by an application, and keep the entire key after the program is uninstalled (incase it is re-installed, want the stored data to remain) Here is the sample code. However, every time I install, it creates the proper key, but when I uninstall via ARP, it removes the entire key. Component Id=foo Guid=xxx Permanent=yes Registry Action=createKey Root=HKLM Key=SOFTWARE\foo\blah/ /Component I've checked the package with ORCA, and it shows the component table with the attribute of 16, which should translate properly to permanent. Even if I manually go in an add a string/Dword, it still all gets removed on uninstall. Am I missing something? (using wix 2) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Permanent Component being removed on uninstall
Verbose log file will explain why it is being uninstalled. -Original Message- From: Dylan Moline (Volt) [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 15:01 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Permanent Component being removed on uninstall Trying to create a registry key which is edited by an application, and keep the entire key after the program is uninstalled (incase it is re-installed, want the stored data to remain) Here is the sample code. However, every time I install, it creates the proper key, but when I uninstall via ARP, it removes the entire key. Component Id=foo Guid=xxx Permanent=yes Registry Action=createKey Root=HKLM Key=SOFTWARE\foo\blah/ /Component I've checked the package with ORCA, and it shows the component table with the attribute of 16, which should translate properly to permanent. Even if I manually go in an add a string/Dword, it still all gets removed on uninstall. Am I missing something? (using wix 2) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Application Installation and Patching Survey for Windows
The Windows SDK blog is asking: How should installation and patching work in future versions of Windows? http://tinyurl.com/55uwr4 -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixDIFxAppExtension and MergeModules
Hmm, that really surprises me. I thought that mergemod.dll was smarter than that. There are no differences on those rows where the merge conflicts happen? Hmm. -Original Message- From: Moradi, Ari [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2008 11:59 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixDIFxAppExtension and MergeModules Mergemod.dll doesn't like trying to merge rows with identical primary keys (even if they are really supposed to be the same thing. Here's some log output since you asked for it :) I created my two merge modules, then I ran: Orca.exe -f ProductFeature -m DriverMergeModule1.msm -l merge.log -c Test.msi I checked Test.msi and merge.log and sure enough, DriverMergeModule1.msm was successfully merged. Then I deleted merge.log and ran: Orca.exe -f ProductFeature -m DriverMergeModule2.msm -l merge.log -c Test.msi Here's some snippets from the merge.log: Opened MSI Database: Test.msi Opened Merge Module: DriverMergeModule2.msm ... Merging Table: Binary o Merging row: DIFxApp.dll.B913F2A8_9BB5_40E4_9D7E_2541BC55A38D o Merging row: DIFxAppA.dll.B913F2A8_9BB5_40E4_9D7E_2541BC55A38D ... Merging Table: CustomAction o Merging row: MsiProcessDrivers Error: Failed to merge Row: MsiProcessDrivers into Table: CustomAction o Merging row: MsiInstallDrivers Error: Failed to merge Row: MsiInstallDrivers into Table: CustomAction o Merging row: MsiUninstallDrivers Error: Failed to merge Row: MsiUninstallDrivers into Table: CustomAction o Merging row: MsiRollbackInstall Error: Failed to merge Row: MsiRollbackInstall into Table: CustomAction o Merging row: MsiCleanupOnSuccess Error: Failed to merge Row: MsiCleanupOnSuccess into Table: CustomAction ... Error: Merge conflict in Database Table: `InstallExecuteSequence` - Action: `MsiProcessDrivers` Error: Merge conflict in Database Table: `InstallExecuteSequence` - Action: `MsiCleanupOnSuccess` Error: Merge conflict in Database Table: `CustomAction` Module Table: `CustomAction` - Row(s): `MsiProcessDrivers` Error: Merge conflict in Database Table: `CustomAction` Module Table: `CustomAction` - Row(s): `MsiInstallDrivers` Error: Merge conflict in Database Table: `CustomAction` Module Table: `CustomAction` - Row(s): `MsiUninstallDrivers` Error: Merge conflict in Database Table: `CustomAction` Module Table: `CustomAction` - Row(s): `MsiRollbackInstall` Error: Merge conflict in Database Table: `CustomAction` Module Table: `CustomAction` - Row(s): `MsiCleanupOnSuccess` Total merge conflicts: 7 Closed Merge Module. Warning: Changes were not saved to MSI Database. Closed MSI Database. -Ari -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2008 1:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WixDIFxAppExtension and MergeModules If the rows are duplicate, I thought mergemod.dll would let them through. Is it more accurate to say that the DIFxApp actions Id's have been modularized and that is colliding? Can you maybe share out a merge.log that shows the merge problems? -Original Message- From: Moradi, Ari [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2008 11:16 To: wix-users@lists.sourceforge.net Subject: [WiX-users] WixDIFxAppExtension and MergeModules Hi folks, I'm having a problem with the WixDIFxAppExtension when I'm using it in merge modules, and I'm wondering if someone can offer me a simpler workaround than what I'm currently planning on doing :) The problem is caused when we try to build two different merge modules using WIX (v3.0.4624.0) that include drivers and then include both those merge modules in one MSI. Both merge module projects link with difxapp_platform.wixlib, which adds the DIFx custom actions in the merge module custom action table: MsiProcessDrivers, MsiInstallDrivers, etc. When those two merge modules are then merged into the same MSI, we obviously get duplicate row errors and the merge fails. My hope would really be that if WIX builds a merge module using WixDifxAppExtension, instead of adding the DIFx custom actions directly if it instead would add a ModuleDependency on the DIFxApp merge module. Then we could merge multiple merge modules that all depend on DIFxApp, and then the DIFxApp merge module would be merged in too to get the custom actions. But that's not what it does, so I'm looking for a workaround... One option we have is to build wixlibs instead of merge modules, but since I'm not guaranteed that consumers of our merge modules are going to use WIX (they might be using InstallShield) that doesn't really work well for our team. The other option I think I have is that instead of using WixDIFxAppExtension, I'll add a CustomTable Id=MsiProcessDrivers... and manually add the rows I need to the table, and then add the Dependency on the DIFxApp merge module too.
Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working
Got this to work switching XmlFile entry for install pass to following XmlConfig entry. util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Action=create Node=document On=install![CDATA[ !-- this line was added by rxp eventing v2.0 service deliverable installer -- add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35/ ]]/util:XmlConfig -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 11:39 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Any tips on why the following xmlfile machine.config install changes are not working? I'm using the following component entries: util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot; Action=createElement / util:XmlConfig Id=RemoveBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions VerifyPath=/configuration/system.serviceModel/extensions/behaviorExtensions/[EMAIL PROTECTED]quot;enableBizTalkHeaderInspectorquot; amp;amp; @type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;[\]] Action=delete Node=element On=uninstall / To try and get this new add / element created during install but finding that no machine.config changes exist after setup completes. configuration system.serviceModel extensions behaviorExtensions . . . . . . add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94 / /behaviorExtensions The verbose logs show the following ExecXmlFile property setting and execution of a similarly named custom action Property(S): ExecXmlFile = 2EUR0EURC:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.configEUR5EUR0EUR/configuration/system.serviceModel/extensions/behaviorExtensionsEURaddEURname=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working
Btw - I was using initially using the following to arrive at my NetFramework20ConfigDir setting for use referencing machine.config file. registry search result. PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR / Directory Id=NETFRAMEWORK20INSTALLROOTDIR Directory Id=NetFramework20ConfigDir Name=CONFIG / /Directory In case of $(var.Platform) = x64 build output the installer was given me a systems is was giving me a WixNetFxExtensions property NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the installRoot registry key lookup. Is that expected? I locally implemented the following and in the local implementation case I get the desired non-Software\Wow6432Node result using the exact same registry search entry. Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property Property Id=NFX20X86INSTALLROOTDIR RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 4:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Got this to work switching XmlFile entry for install pass to following XmlConfig entry. util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Action=create Node=document On=install![CDATA[ !-- this line was added by rxp eventing v2.0 service deliverable installer -- add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35/ ]]/util:XmlConfig -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 11:39 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Any tips on why the following xmlfile machine.config install changes are not working? I'm using the following component entries: util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot; Action=createElement / util:XmlConfig Id=RemoveBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions VerifyPath=/configuration/system.serviceModel/extensions/behaviorExtensions/[EMAIL PROTECTED]quot;enableBizTalkHeaderInspectorquot; amp;amp; @type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;[\]] Action=delete Node=element On=uninstall / To try and get this new add / element created during install but finding that no machine.config changes exist after setup completes. configuration system.serviceModel extensions behaviorExtensions . . . . . . add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94 / /behaviorExtensions The verbose logs show the following ExecXmlFile property setting and execution of a similarly named custom action Property(S): ExecXmlFile = 2EUR0EURC:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.configEUR5EUR0EUR/configuration/system.serviceModel/extensions/behaviorExtensionsEURaddEURname=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0,
[WiX-users] Debugging ExecuteSqlStrings
Hi experts, I’m using WiX 3. I’m trying to debug a possible error in the sql custom action: MSI (s) (68:B4) [15:49:43:129]: Executing op: CustomActionSchedule(Action=ExecuteSqlStrings,ActionType=25601,Source=BinaryData,Target=**,CustomActionData=**) MSI (s) (68:F8) [15:49:43:139]: Invoking remote custom action. DLL: D:\Windows\Installer\MSI612C.tmp, Entrypoint: ExecuteSqlStrings ExecuteSqlStrings: CustomActionData: CoreSqlDatabase€RUIFANRED280B\MAA€€CoreDB€3€1€€€GrantNetworkServiceAdmin€17€EXEC sp_addsrvrolemember NT AUTHORITY\NETWORK SERVICE, …… MSI (c) (58:30) [15:49:45:118]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg Error 26204. Error -2147217900: failed to execute SQL string, error detail: Incorrect syntax near the keyword 'with'. …… MSI (s) (68!24) [15:49:56:154]: Product: Microsoft MAA - Core Database -- Error 26204. Error -2147217900: failed to execute SQL string, error detail: Incorrect syntax near the keyword 'with'. If this statement is a common table expression, an xmlnamespaces clause or a change tracking context clause, the previous statement must be terminated with a semicolon., SQL key: CoreDBSBSQLScript SQL string: riginal error information. …… Action ended 15:49:56: InstallFinalize. Return value 3. I found a function called “ExecuteSqlStrings” under serverca\scaexec. I can’t find the generated scaexec.dll in wix3-binaries.zip. But I can find it in the msi package. Where did this file come from? And I also tried to add “DebugBreak()” in “ExecuteSqlStrings” but it doesn't work. Which can I find the correct entry point of ExecuteSqlStrings? Which is the correct file and line to set break points? And do you have any best practice to debug a running custom action? Thanks, Rui - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Permanent Component being removed on uninstall
And the Component table has something in KeyPath? Phil Wilson -Original Message- From: Dylan Moline (Volt) [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 3:01 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Permanent Component being removed on uninstall Trying to create a registry key which is edited by an application, and keep the entire key after the program is uninstalled (incase it is re-installed, want the stored data to remain) Here is the sample code. However, every time I install, it creates the proper key, but when I uninstall via ARP, it removes the entire key. Component Id=foo Guid=xxx Permanent=yes Registry Action=createKey Root=HKLM Key=SOFTWARE\foo\blah/ /Component I've checked the package with ORCA, and it shows the component table with the attribute of 16, which should translate properly to permanent. Even if I manually go in an add a string/Dword, it still all gets removed on uninstall. Am I missing something? (using wix 2) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Permanent Component being removed on uninstall
The log is showing this:
MSI (s) (98:20) [16:09:09:028]: Disallowing uninstallation of component:
{5703B886-7D29-45D1-9EFF-35198D58EC20} since another client exists
And then this:
MSI (s) (98:2C) [16:18:48:399]: Executing op:
ComponentUnregister(ComponentId={5703B886-7D29-45D1-9EFF-35198D58EC20},,BinaryType=0,PreviouslyPinned=1)
Un-registering it shouldn't remove it should it?
I'm not seeing anywhere else where its being called to remove (except
RemoveRegistryValues, and even if I suppress that (which I don't want to have
to do)) it still removes it.
-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 3:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Permanent Component being removed on uninstall
Verbose log file will explain why it is being uninstalled.
-Original Message-
From: Dylan Moline (Volt) [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 15:01
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Permanent Component being removed on uninstall
Trying to create a registry key which is edited by an application, and keep the
entire key after the program is uninstalled (incase it is re-installed, want
the stored data to remain)
Here is the sample code. However, every time I install, it creates the proper
key, but when I uninstall via ARP, it removes the entire key.
Component Id=foo Guid=xxx Permanent=yes
Registry Action=createKey Root=HKLM Key=SOFTWARE\foo\blah/
/Component
I've checked the package with ORCA, and it shows the component table with the
attribute of 16, which should translate properly to permanent.
Even if I manually go in an add a string/Dword, it still all gets removed on
uninstall.
Am I missing something? (using wix 2)
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Permanent Component being removed on uninstall
Yes, with or without a KeyPath there, is still is removed. ~Dylan -Original Message- From: Wilson, Phil [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 4:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Permanent Component being removed on uninstall And the Component table has something in KeyPath? Phil Wilson -Original Message- From: Dylan Moline (Volt) [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 3:01 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Permanent Component being removed on uninstall Trying to create a registry key which is edited by an application, and keep the entire key after the program is uninstalled (incase it is re-installed, want the stored data to remain) Here is the sample code. However, every time I install, it creates the proper key, but when I uninstall via ARP, it removes the entire key. Component Id=foo Guid=xxx Permanent=yes Registry Action=createKey Root=HKLM Key=SOFTWARE\foo\blah/ /Component I've checked the package with ORCA, and it shows the component table with the attribute of 16, which should translate properly to permanent. Even if I manually go in an add a string/Dword, it still all gets removed on uninstall. Am I missing something? (using wix 2) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How would people handle this situation
Sean Farrow wrote: do a registry search for the uninstallation executable, if the exe is found run it. I can accomplish the first part (registry search), but I need the custom action to come before any ui dialogues. Wher should I sequence this ca? Unless the uninstaller runs with limited user privileges, it's going to fail on Windows Vista and Server 2008, because it won't be able to get elevated privileges. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] cannot find VCProjectEngine (again, ignore the previous one if it went through)
Jason Ding wrote: Thanks for the reply. I guess you misunderstood my question - I am using VC2008 and .Net Framework 3.5, but when I build I got error message about missing VCProjectEngine and suggest to install VC2005 and .Net Framework 2.0. I understand that. I'm asking if you're trying to create a .sln that contains a .wixproj that refers to project variables from a .vcproj. If so, it's a known limitation with .vcproj support in .wixprojs. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install Localisation
Neil Sleightholm wrote: 2. Every time I run light it will create a new product code but I don't want that, I want one product code and simply install with a different UI language. From what I have read this seems to be a valid approach. The MSI SDK disagrees. In fact, it's unusually unambiguous [emphasis mine]: A localized product is considered a different product. For example, the German and English versions of an application are considered two different products and /must /have different product codes. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Debugging ExecuteSqlStrings
Rui Fan (MDT InfoTech) wrote: Error 26204. Error -2147217900: failed to execute SQL string, error detail: Incorrect syntax near the keyword 'with'. …… MSI (s) (68!24) [15:49:56:154]: Product: Microsoft MAA - Core Database -- Error 26204. Error -2147217900: failed to execute SQL string, error detail: Incorrect syntax near the keyword 'with'. If this statement is a common table expression, an xmlnamespaces clause or a change tracking context clause, the previous statement must be terminated with a semicolon., SQL key: CoreDBSBSQLScript SQL string: riginal error information. …… The error message is coming from SQL, not the custom action. You'll have better luck debugging the SQL strings. I found a function called “ExecuteSqlStrings” under serverca\scaexec. I can’t find the generated scaexec.dll in wix3-binaries.zip. It's embedded in WixSqlExtension.dll. If you want to debug the code, you'll need to rebuild the scaexec.dll and WixSqlExtension.dll. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Permanent Component being removed on uninstall
Dylan Moline (Volt) wrote: Un-registering it shouldn't remove it should it? No, it's merely indicating that this product is going away, so should no longer be considered a client of the component. Look elsewhere in the log for that registry key. Also look at custom actions that directly manipulate the registry. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working
Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit correctly. -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 16:24 To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Btw - I was using initially using the following to arrive at my NetFramework20ConfigDir setting for use referencing machine.config file. registry search result. PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR / Directory Id=NETFRAMEWORK20INSTALLROOTDIR Directory Id=NetFramework20ConfigDir Name=CONFIG / /Directory In case of $(var.Platform) = x64 build output the installer was given me a systems is was giving me a WixNetFxExtensions property NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the installRoot registry key lookup. Is that expected? I locally implemented the following and in the local implementation case I get the desired non-Software\Wow6432Node result using the exact same registry search entry. Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property Property Id=NFX20X86INSTALLROOTDIR RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 4:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Got this to work switching XmlFile entry for install pass to following XmlConfig entry. util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Action=create Node=document On=install![CDATA[ !-- this line was added by rxp eventing v2.0 service deliverable installer -- add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35/ ]]/util:XmlConfig -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 11:39 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Any tips on why the following xmlfile machine.config install changes are not working? I'm using the following component entries: util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot; Action=createElement / util:XmlConfig Id=RemoveBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions VerifyPath=/configuration/system.serviceModel/extensions/behaviorExtensions/[EMAIL PROTECTED]quot;enableBizTalkHeaderInspectorquot; amp;amp; @type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot;[\]] Action=delete Node=element On=uninstall / To try and get this new add / element created during install but finding that no machine.config changes exist after setup completes. configuration system.serviceModel extensions behaviorExtensions . . . . . . add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94 / /behaviorExtensions The verbose logs show the following ExecXmlFile property setting and execution of a similarly named custom action Property(S):
Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working
The NetFxExtension.wxs contains the following for assignment of NETFRAMEWORK20INSTALLROOTDIR which I would expect to do the right thing for Target=X64 build output cases. Fragment Property Id=NETFRAMEWORK20INSTALLROOTDIR Secure=yes RegistrySearch Id=NetFxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=NetFx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property /Fragment Could the issue be that C:\Program Files (x86)\Windows Installer XML v3\bin\WixNetFxExtension.dll installed by the Wix3_x64.msi installer was built with Target=x86 versus Target=x64? -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:07 PM To: General discussion for Windows Installer XML toolset.; Robert O'Brien Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit correctly. -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 16:24 To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Btw - I was using initially using the following to arrive at my NetFramework20ConfigDir setting for use referencing machine.config file. registry search result. PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR / Directory Id=NETFRAMEWORK20INSTALLROOTDIR Directory Id=NetFramework20ConfigDir Name=CONFIG / /Directory In case of $(var.Platform) = x64 build output the installer was given me a systems is was giving me a WixNetFxExtensions property NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the installRoot registry key lookup. Is that expected? I locally implemented the following and in the local implementation case I get the desired non-Software\Wow6432Node result using the exact same registry search entry. Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property Property Id=NFX20X86INSTALLROOTDIR RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 4:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Got this to work switching XmlFile entry for install pass to following XmlConfig entry. util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Action=create Node=document On=install![CDATA[ !-- this line was added by rxp eventing v2.0 service deliverable installer -- add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35/ ]]/util:XmlConfig -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 11:39 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Any tips on why the following xmlfile machine.config install changes are not working? I'm using the following component entries: util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e2c282dc0883bc94quot; Action=createElement / util:XmlConfig Id=RemoveBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions VerifyPath=/configuration/system.serviceModel/extensions/behaviorExtensions/[EMAIL PROTECTED]quot;enableBizTalkHeaderInspectorquot; amp;amp;
Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working
No, the problem is that the RegistrySearch isn't set 64-bit. So it's always searching 32-bit. That's the bug. Can you file it? -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 19:15 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working The NetFxExtension.wxs contains the following for assignment of NETFRAMEWORK20INSTALLROOTDIR which I would expect to do the right thing for Target=X64 build output cases. Fragment Property Id=NETFRAMEWORK20INSTALLROOTDIR Secure=yes RegistrySearch Id=NetFxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=NetFx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property /Fragment Could the issue be that C:\Program Files (x86)\Windows Installer XML v3\bin\WixNetFxExtension.dll installed by the Wix3_x64.msi installer was built with Target=x86 versus Target=x64? -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:07 PM To: General discussion for Windows Installer XML toolset.; Robert O'Brien Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit correctly. -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 16:24 To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Btw - I was using initially using the following to arrive at my NetFramework20ConfigDir setting for use referencing machine.config file. registry search result. PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR / Directory Id=NETFRAMEWORK20INSTALLROOTDIR Directory Id=NetFramework20ConfigDir Name=CONFIG / /Directory In case of $(var.Platform) = x64 build output the installer was given me a systems is was giving me a WixNetFxExtensions property NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the installRoot registry key lookup. Is that expected? I locally implemented the following and in the local implementation case I get the desired non-Software\Wow6432Node result using the exact same registry search entry. Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property Property Id=NFX20X86INSTALLROOTDIR RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 4:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Got this to work switching XmlFile entry for install pass to following XmlConfig entry. util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Action=create Node=document On=install![CDATA[ !-- this line was added by rxp eventing v2.0 service deliverable installer -- add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35/ ]]/util:XmlConfig -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 11:39 AM To: 'General discussion for Windows Installer XML toolset.' Subject: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Any tips on why the following xmlfile machine.config install changes are not working? I'm using the following component entries: util:XmlFile Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Name=add Value=name=quot;enableBizTalkHeaderInspectorquot; type=quot;Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral,
Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working
Bug Filed. For clarification how come my locally implemented identical registry search based property assignment, excerpt from earlier shown here, would be working in 64-bit installer usage? Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:29 PM To: Robert O'Brien; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working No, the problem is that the RegistrySearch isn't set 64-bit. So it's always searching 32-bit. That's the bug. Can you file it? -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 19:15 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working The NetFxExtension.wxs contains the following for assignment of NETFRAMEWORK20INSTALLROOTDIR which I would expect to do the right thing for Target=X64 build output cases. Fragment Property Id=NETFRAMEWORK20INSTALLROOTDIR Secure=yes RegistrySearch Id=NetFxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=NetFx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property /Fragment Could the issue be that C:\Program Files (x86)\Windows Installer XML v3\bin\WixNetFxExtension.dll installed by the Wix3_x64.msi installer was built with Target=x86 versus Target=x64? -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:07 PM To: General discussion for Windows Installer XML toolset.; Robert O'Brien Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit correctly. -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 16:24 To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Btw - I was using initially using the following to arrive at my NetFramework20ConfigDir setting for use referencing machine.config file. registry search result. PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR / Directory Id=NETFRAMEWORK20INSTALLROOTDIR Directory Id=NetFramework20ConfigDir Name=CONFIG / /Directory In case of $(var.Platform) = x64 build output the installer was given me a systems is was giving me a WixNetFxExtensions property NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the installRoot registry key lookup. Is that expected? I locally implemented the following and in the local implementation case I get the desired non-Software\Wow6432Node result using the exact same registry search entry. Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property Property Id=NFX20X86INSTALLROOTDIR RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 4:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Got this to work switching XmlFile entry for install pass to following XmlConfig entry. util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Action=create Node=document On=install![CDATA[ !-- this line was added by rxp eventing v2.0 service deliverable installer -- add name=enableBizTalkHeaderInspector type=Microsoft.IT.RelationshipManagement.Services.WcfExtensions.HeaderInspectorBehaviorElement, Microsoft.IT.RelationshipManagement.Services.WcfExtensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35/ ]]/util:XmlConfig -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 11:39 AM To: 'General discussion
Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working
Are you setting the platform on the command-line to candle? -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 19:39 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Bug Filed. For clarification how come my locally implemented identical registry search based property assignment, excerpt from earlier shown here, would be working in 64-bit installer usage? Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:29 PM To: Robert O'Brien; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working No, the problem is that the RegistrySearch isn't set 64-bit. So it's always searching 32-bit. That's the bug. Can you file it? -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 19:15 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working The NetFxExtension.wxs contains the following for assignment of NETFRAMEWORK20INSTALLROOTDIR which I would expect to do the right thing for Target=X64 build output cases. Fragment Property Id=NETFRAMEWORK20INSTALLROOTDIR Secure=yes RegistrySearch Id=NetFxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=NetFx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property /Fragment Could the issue be that C:\Program Files (x86)\Windows Installer XML v3\bin\WixNetFxExtension.dll installed by the Wix3_x64.msi installer was built with Target=x86 versus Target=x64? -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:07 PM To: General discussion for Windows Installer XML toolset.; Robert O'Brien Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit correctly. -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 16:24 To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Btw - I was using initially using the following to arrive at my NetFramework20ConfigDir setting for use referencing machine.config file. registry search result. PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR / Directory Id=NETFRAMEWORK20INSTALLROOTDIR Directory Id=NetFramework20ConfigDir Name=CONFIG / /Directory In case of $(var.Platform) = x64 build output the installer was given me a systems is was giving me a WixNetFxExtensions property NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the installRoot registry key lookup. Is that expected? I locally implemented the following and in the local implementation case I get the desired non-Software\Wow6432Node result using the exact same registry search entry. Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property Property Id=NFX20X86INSTALLROOTDIR RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 4:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Got this to work switching XmlFile entry for install pass to following XmlConfig entry. util:XmlConfig Id=AddBehaviorExtensionsEnableBizTalkHeaderInspector File=[NetFramework20ConfigDir]machine.config ElementPath=/configuration/system.serviceModel/extensions/behaviorExtensions Action=create Node=document On=install![CDATA[ !-- this line was added by rxp eventing v2.0 service deliverable installer -- add name=enableBizTalkHeaderInspector
Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working
Not sure I'm just using standard issue file | new | wix project template generated wixproj to wrap build process with Build Configuration Platform=x64 enabled. -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:40 PM To: Robert O'Brien; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Are you setting the platform on the command-line to candle? -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 19:39 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Bug Filed. For clarification how come my locally implemented identical registry search based property assignment, excerpt from earlier shown here, would be working in 64-bit installer usage? Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:29 PM To: Robert O'Brien; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working No, the problem is that the RegistrySearch isn't set 64-bit. So it's always searching 32-bit. That's the bug. Can you file it? -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 19:15 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working The NetFxExtension.wxs contains the following for assignment of NETFRAMEWORK20INSTALLROOTDIR which I would expect to do the right thing for Target=X64 build output cases. Fragment Property Id=NETFRAMEWORK20INSTALLROOTDIR Secure=yes RegistrySearch Id=NetFxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=NetFx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property /Fragment Could the issue be that C:\Program Files (x86)\Windows Installer XML v3\bin\WixNetFxExtension.dll installed by the Wix3_x64.msi installer was built with Target=x86 versus Target=x64? -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:07 PM To: General discussion for Windows Installer XML toolset.; Robert O'Brien Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit correctly. -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 16:24 To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Btw - I was using initially using the following to arrive at my NetFramework20ConfigDir setting for use referencing machine.config file. registry search result. PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR / Directory Id=NETFRAMEWORK20INSTALLROOTDIR Directory Id=NetFramework20ConfigDir Name=CONFIG / /Directory In case of $(var.Platform) = x64 build output the installer was given me a systems is was giving me a WixNetFxExtensions property NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the installRoot registry key lookup. Is that expected? I locally implemented the following and in the local implementation case I get the desired non-Software\Wow6432Node result using the exact same registry search entry. Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property Property Id=NFX20X86INSTALLROOTDIR RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20X86InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 4:17 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Got this to work switching XmlFile entry for install pass to following XmlConfig
[WiX-users] How to run another msi from our msi installer
Hello , how can i run another msi (like xml parse installer , or dot net framework) from my installer? ___ Dapatkan nama yang Anda sukai! Sekarang Anda dapat memiliki email di @ymail.com dan @rocketmail.com. http://mail.promotions.yahoo.com/newdomains/id/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working
Yeah, the InstallerPlatform=$(InstallerPlatform) Is probably being set. You can see it as the -arch switch to candle. -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 19:43 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Not sure I'm just using standard issue file | new | wix project template generated wixproj to wrap build process with Build Configuration Platform=x64 enabled. -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:40 PM To: Robert O'Brien; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Are you setting the platform on the command-line to candle? -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 19:39 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Bug Filed. For clarification how come my locally implemented identical registry search based property assignment, excerpt from earlier shown here, would be working in 64-bit installer usage? Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:29 PM To: Robert O'Brien; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working No, the problem is that the RegistrySearch isn't set 64-bit. So it's always searching 32-bit. That's the bug. Can you file it? -Original Message- From: Robert O'Brien Sent: Monday, December 01, 2008 19:15 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working The NetFxExtension.wxs contains the following for assignment of NETFRAMEWORK20INSTALLROOTDIR which I would expect to do the right thing for Target=X64 build output cases. Fragment Property Id=NETFRAMEWORK20INSTALLROOTDIR Secure=yes RegistrySearch Id=NetFxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=NetFx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property /Fragment Could the issue be that C:\Program Files (x86)\Windows Installer XML v3\bin\WixNetFxExtension.dll installed by the Wix3_x64.msi installer was built with Target=x86 versus Target=x64? -Original Message- From: Rob Mensching Sent: Monday, December 01, 2008 7:07 PM To: General discussion for Windows Installer XML toolset.; Robert O'Brien Subject: RE: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Sounds like a bug in the NETFRAMEWORK20INSTALLROOTDIR not following 64-bit correctly. -Original Message- From: Robert O'Brien [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 16:24 To: Robert O'Brien; 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] any tips on why the following xmlfile machine.config install changes are not working Btw - I was using initially using the following to arrive at my NetFramework20ConfigDir setting for use referencing machine.config file. registry search result. PropertyRef Id=NETFRAMEWORK20INSTALLROOTDIR / Directory Id=NETFRAMEWORK20INSTALLROOTDIR Directory Id=NetFramework20ConfigDir Name=CONFIG / /Directory In case of $(var.Platform) = x64 build output the installer was given me a systems is was giving me a WixNetFxExtensions property NETFRAMEWORK20INSTALLROOTDIR result that was using System\Wow6432Node for the installRoot registry key lookup. Is that expected? I locally implemented the following and in the local implementation case I get the desired non-Software\Wow6432Node result using the exact same registry search entry. Property Id=NFX20INSTALLROOTDIR RegistrySearch Id=NfxInstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20InstallRootSearch Path=v2.0.50727 Depth=0 / /RegistrySearch /Property Property Id=NFX20X86INSTALLROOTDIR RegistrySearch Id=NfxX86InstallRootForNetfx20Search Type=raw Root=HKLM Key=Software\Wow6432Node\Microsoft\.NETFramework Name=InstallRoot DirectorySearch Id=Nfx20X86InstallRootSearch
Re: [WiX-users] How to run another msi from our msi installer
Running an msi from another msi is not supported, and will not work. What you have to do is create a bootstrapper. This is an exe file that will check for certain prerequisites and install them, and then it will run your msi. I have found the 'bootstrap manifest generator' to be of use (it is a bit unstable though). Have a look here, http://code.msdn.microsoft.com/bmg Also you can use visual studio to create a bootstrapper for you. When you create an installer package within visual studio it gives you bootstrapper options, and then spits out a file called setup.exe Search around on google, there is heaps out there on the subject. Otherwise get back to me if you want more of a hand. On Tue, Dec 2, 2008 at 4:45 PM, zhwee ant [EMAIL PROTECTED] wrote: Hello , how can i run another msi (like xml parse installer , or dot net framework) from my installer? ___ Dapatkan nama yang Anda sukai! Sekarang Anda dapat memiliki email di @ymail.com dan @rocketmail.com. http://mail.promotions.yahoo.com/newdomains/id/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [WIX-Users]
Hi All, I have a WIX installer that uses the 'LocalAppDataFolder' property to get the data folder directory (it is different for different OSs). I want to do the same for the 'My documents' folder. What is the corresponding property? Thanks, Peter. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] My documents folder from within WIX
Hi All, I have a WIX installer that uses the 'LocalAppDataFolder' property to get the data folder directory (it is different for different OSs). I want to do the same for the 'My documents' folder. What is the corresponding property? Thanks, Peter. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WIX-Users]
http://msdn.microsoft.com/en-us/library/aa370905(VS.85).aspx#system_folder_properties -Original Message- From: Peter McClymont [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 20:35 To: wix-users@lists.sourceforge.net Subject: [WiX-users] [WIX-Users] Hi All, I have a WIX installer that uses the 'LocalAppDataFolder' property to get the data folder directory (it is different for different OSs). I want to do the same for the 'My documents' folder. What is the corresponding property? Thanks, Peter. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [WIX-Users] Not allowed to installer a folder with spaces in it?
Hi All, I have this code snippet in my WIX script, DirectoryRef Id=FlowPlanDirectory Component Id=MyFlowPlanDirectory Guid=FF63AA3E-C02D-11DD-AD5B-1C9356D89593 CreateFolder Directory =My iCalibra Flow Plans/ RemoveFolder Id=FlowPlanDirectory On=uninstall/ RemoveFile Id=FlowPlanDirectoryContents Name=* On=uninstall/ /Component /DirectoryRef Which should create a directory called Documents\My iCalibra Flow Plans Instead when I compile it I get an error, The CreateFolder/@Directory attribute's value, 'My iCalibra Flow Plans', is not a legal identifier. Identifiers may contain ASCII characters A-Z, a-z, digits, underscores (_), or periods (.). Every identifier must begin with either a letter or an underscore. C:\Dev\iC3\Source\iC3InstallerWIX\Product.wxs Is there any way around this? Thanks, Peter. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WIX-Users] Not allowed to installer a folder with spaces in it?
Peter McClymont wrote: CreateFolder Directory =My iCalibra Flow Plans/ The CreateFolder/@Directory attribute value is the ID of a directory. If you want to create a subdirectory with that name, use a Directory element under the DirectoryRef. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WIX-Users] Not allowed to installer a folder with spaces in it?
Hi Peter, Directory refers to a Directory Id, therefore it cannot contains spaces. What you want to accomplish is: DirectoryRef Id=FlowPlanDirectory Directory Id=MyiCalibraFlowPlans Name=My iCalibra Flow Plans Component Id=MyFlowPlanDirectory Guid=FF63AA3E-C02D-11DD-AD5B-1C9356D89593 CreateFolder / RemoveFolder Id=FlowPlanDirectory On=uninstall/ RemoveFile Id=FlowPlanDirectoryContents Name=* On=uninstall/ /Component /Directory /DirectoryRef On Tue, Dec 2, 2008 at 8:11 AM, Peter McClymont [EMAIL PROTECTED]wrote: Hi All, I have this code snippet in my WIX script, DirectoryRef Id=FlowPlanDirectory Component Id=MyFlowPlanDirectory Guid=FF63AA3E-C02D-11DD-AD5B-1C9356D89593 CreateFolder Directory =My iCalibra Flow Plans/ RemoveFolder Id=FlowPlanDirectory On=uninstall/ RemoveFile Id=FlowPlanDirectoryContents Name=* On=uninstall/ /Component /DirectoryRef Which should create a directory called Documents\My iCalibra Flow Plans Instead when I compile it I get an error, The CreateFolder/@Directory attribute's value, 'My iCalibra Flow Plans', is not a legal identifier. Identifiers may contain ASCII characters A-Z, a-z, digits, underscores (_), or periods (.). Every identifier must begin with either a letter or an underscore. C:\Dev\iC3\Source\iC3InstallerWIX\Product.wxs Is there any way around this? Thanks, Peter. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install Localisation
Good point (I don't care as we only do major upgrades - at the moment) but this is a simple solution. Neil -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 22:43 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation Most people that are attempting to do what you are doing, care about their ProductCodes so they can tightly manage upgrades in the future. -Original Message- From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 14:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation I guess it is laziness on my part :-) I am just going to have to write some code. I just strikes me as a common requirement to generate a transform without a different ProductCode - I guess that makes it a feature request. May be it should be a torch change rather than light. I'll look at that package code issue and see what I can find. Neil -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 22:08 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 2. The PackageCode should be regenerated with every run of light. If not, that would be a bad bug. There is no scope like you are asking for. IMHO, if you want to manage your ProductCode then you should manage your ProductCode. You could open a feature request if you want. Nothing in you scenario is completely unexpected. Generating transforms is complete supported. You'll need something to apply the transforms at run time, presumably. The bugs in the WiX toolset are being fixed, BTW. -Original Message- From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 13:59 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 2. Is there any scope for making this optional or replacing Product/@Id=* on the first pass of light? The PackageCode is not regenerated on every run of light, is this not the same? I can't find any good documentation on Windows Installer localisation, do you think I am doing the right thing to localise my install or is it my approach that is floored. Thanks Neil -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 20:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 1. Don't know. 2. If you use Product/@Id=* then it always generates a new ProductCode. If you don't want that, don't use *. 3. No. There are cases where you'll end up with a binary .wixout even if you don't use -bf, especially around the use of CustomActions. -Original Message- From: Neil Sleightholm [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 10:34 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation Having worked through a few bugs in light I am now back to looking at this problem again. What I would like to do is create an MSI with a separate transform (MST) for each language. So the process I intend to use is: 1. Create wixout for my install using the -sloc parameter. 2. Link the wixout to create the English MSI. 3. For each language run light on the wixout to create a new translated MSI or wixout. 4. Use torch to create an MST for each language from 3. Until the next WiX release I am not able to try this but I can see a couple of problems: 1. The documentation for torch says that if you use a wixout input file it will only create a wixout (-xo set by default if -xi set). Is this correct? If it is, how do you create an MST from a wixout? 2. Every time I run light it will create a new product code but I don't want that, I want one product code and simply install with a different UI language. From what I have read this seems to be a valid approach. Can anyone suggest how I can do this? 3. I thought I could solve 2 but editing the wixout file and putting in my own ProductCode so that it is not regenerated but it appears to start with some binary data. I think that it is always binding the files into wixout not just when -bf is used. Does this sound like a bug? Thanks for your help Neil Neil Sleightholm X2 Systems Limited [EMAIL PROTECTED] -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: 06 November 2008 22:31 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation 0. *Every* MSI should have a different PackageCode. Even two builds of the same MSI. 1. You *can* have different ProductCodes for all of your languages. Depends on what your SxS story is. 2. The most efficient way I've seen this done is: a. Link to .wixout files. This will get you everything but the final localized build. b. Use cab cache to minimize the number of cabinets rebuilt. If
Re: [WiX-users] [WIX-Users] Not allowed to installer a folder with spaces in it?
Thanks you guys are right on the Money. Thanks for your help. On Tue, Dec 2, 2008 at 7:30 PM, Eitan Behar [EMAIL PROTECTED] wrote: Hi Peter, Directory refers to a Directory Id, therefore it cannot contains spaces. What you want to accomplish is: DirectoryRef Id=FlowPlanDirectory Directory Id=MyiCalibraFlowPlans Name=My iCalibra Flow Plans Component Id=MyFlowPlanDirectory Guid=FF63AA3E-C02D-11DD-AD5B-1C9356D89593 CreateFolder / RemoveFolder Id=FlowPlanDirectory On=uninstall/ RemoveFile Id=FlowPlanDirectoryContents Name=* On=uninstall/ /Component /Directory /DirectoryRef On Tue, Dec 2, 2008 at 8:11 AM, Peter McClymont [EMAIL PROTECTED]wrote: Hi All, I have this code snippet in my WIX script, DirectoryRef Id=FlowPlanDirectory Component Id=MyFlowPlanDirectory Guid=FF63AA3E-C02D-11DD-AD5B-1C9356D89593 CreateFolder Directory =My iCalibra Flow Plans/ RemoveFolder Id=FlowPlanDirectory On=uninstall/ RemoveFile Id=FlowPlanDirectoryContents Name=* On=uninstall/ /Component /DirectoryRef Which should create a directory called Documents\My iCalibra Flow Plans Instead when I compile it I get an error, The CreateFolder/@Directory attribute's value, 'My iCalibra Flow Plans', is not a legal identifier. Identifiers may contain ASCII characters A-Z, a-z, digits, underscores (_), or periods (.). Every identifier must begin with either a letter or an underscore. C:\Dev\iC3\Source\iC3InstallerWIX\Product.wxs Is there any way around this? Thanks, Peter. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install Localisation
I read that and at first it made sense but as it doesn't put it in context I chose to ignore it! I can see it makes sense if the French install should run side-by-side with German but if the only difference is the install wizard UI and this is controlled via a transform not separate MSI I would expect to see the same ProductCode. In fact when you run torch if displays a warning if you are changing the ProductCode advising against it, so someone agrees with me. Neil -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: 02 December 2008 01:48 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Install Localisation Neil Sleightholm wrote: 2. Every time I run light it will create a new product code but I don't want that, I want one product code and simply install with a different UI language. From what I have read this seems to be a valid approach. The MSI SDK disagrees. In fact, it's unusually unambiguous [emphasis mine]: A localized product is considered a different product. For example, the German and English versions of an application are considered two different products and /must /have different product codes. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Please unsubscribe me
- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] XmlConfig
Hi! I'm trying to use XmlConig to modify an existing file on the computer. Below is a testconfiguration that I have started with to see if I can make XmlConfig to do want I want it to do. When I run the installtion no errors are reported, the dummy.xml is installed but the c:\temp\settings.xml is not modified. I think I have got the ElementPath right, I have tried using XmlFile with the same ElementPath on a file that is installed by the package and then the file is modified. I have logged the the installation and the XmlConfig is called. Has any one any idea of what i'm doing wrong? Kind refards Hans Wix xml: ?xml version=1.0 encoding=Windows-1252? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Product Name=Foobar 1.0 Id=15631406-D933-456b-AE2C-EC50894CC31E Language=1033 Codepage=1252 Version=1.0.0 Manufacturer=Acme Ltd. UpgradeCode=A72070F6-AD0F-4dec-8723-66D94A18A7ED Package Keywords=Installer Description=Acme's Foobar 1.0 Installer Comments=Foobar is a registered trademark of Acme Ltd. Manufacturer=Acme Ltd. InstallerVersion=100 Languages=1033 Compressed=yes SummaryCodepage=1252/ Media Id=1 Cabinet=Sample.cab EmbedCab=yes DiskPrompt=CD-ROM #1/ Property Id=DiskPrompt Value=Acme's Foobar 1.0 Installation [1]/ Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=PFiles Directory Id=Acme Name=Acme Directory Id=INSTALLDIR Name=Foobar1 Component Id=Dummy Guid=F72070F6-AD0F--8723-66D94A18A7ED File Id=XmlSettings Name=dummy.xml DiskId=1 Source=settings.xml Vital=yes/ /Component /Directory /Directory /Directory /Directory Component Id=CustomAction.ModifyPacketXml KeyPath=yes Guid=F72070F6-AD0F-4DEC-8723-66D94A18A7ED Directory=TARGETDIR util:XmlConfig Id=XmlSettings1 File=C:\temp\settings.xml Action=create Name=InfoType ElementPath=//Categories/[EMAIL PROTECTED]'VectorMap'[\]]/InfoTypes On=install Sequence=1/ util:XmlConfig Id=XmlSettings2 File=C:\temp\settings.xml Name=Name Value=Roads ElementPath=//Categories/Category/InfoTypes/InfoType[\[]not(@Name) and not(@RefersTo)[\]] On=install Sequence=2/ util:XmlConfig Id=XmlSettings3 File=C:\temp\settings.xml Name=IsReoderable Value=true ElementPath=//Categories/Category/InfoTypes/[EMAIL PROTECTED]'Roads'[\]] On=install Sequence=3/ util:XmlConfig Id=XmlSettings4 File=C:\temp\settings.xml Action=create Name=DisplayName ElementPath=//Categories/Category/InfoTypes/[EMAIL PROTECTED]'Roads'[\]] On=install Sequence=4/ util:XmlConfig Id=XmlSettings5 File=C:\temp\settings.xml Name=Name Value=Väg ElementPath=//Categories/Category/InfoTypes/InfoType/DisplayName[\[]not(@Name)[\]] On=install Sequence=5/ /Component Feature Id=Complete Level=1 ComponentRef Id=CustomAction.ModifyPacketXml/ ComponentRef Id=Dummy/ /Feature /Product /Wix Log: MSI (s) (14:80) [08:09:54:823]: Doing action: SchedXmlConfig MSI (s) (14:80) [08:09:54:823]: Note: 1: 2205 2: 3: ActionText Action start 08:09:54: SchedXmlConfig. MSI (s) (14:D0) [08:09:54:932]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI1335.tmp, Entrypoint: SchedXmlConfig MSI (s) (14:D4) [08:09:54:932]: Generating random cookie. MSI (s) (14:D4) [08:09:54:932]: Created Custom Action Server with PID 2572 (0xA0C). MSI (s) (14:8C) [08:09:54:964]: Running as a service. MSI (s) (14:8C) [08:09:54:964]: Hello, I'm your 32bit Impersonated custom action server. Action ended 08:09:55: SchedXmlConfig. Return value 1. MSI (s) (14:80) [08:09:55:667]: Doing action: RegisterUser MSI (s) (14:80) [08:09:55:667]: Note: 1: 2205 2: 3: ActionText -- View this message in context: http://n2.nabble.com/XmlConfig-tp1602806p1602806.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
