Re: [WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application
Sorry to bring up the issue again. Does anyone happen to know the answer of this issue? Thanks. From: little.forest little.for...@ymail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tue, February 22, 2011 1:32:24 PM Subject: Re: [WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application If you happen to know the answer, please let us know. Basically, there are some strange problems if the app is launched right after installation. But it works fine if the app is triggered from the system Start menu. Initially I thought this is our app's problem. But some of our developers dug in and try to convince me that the Integrity Level is different between launching it right after installation and triggered from Start menu. But I'm not sure they are correct or not. So my question is, why they have different Integrity Level? And how to make it the same as normal cases. Thanks. From: little.forest little.for...@ymail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Mon, February 21, 2011 1:12:51 PM Subject: Re: [WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application Thanks Rob for your reply. Honestly, I'm not sure when the custom action is scheduled because I took the example(How To: Run the Installed Application After Setup) from Wix.chm. Here's our code: Property Id=WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT Value=!(loc.LaunchAppString) $(var.ApplicationName) / Property Id=WixShellExecTarget Value=[INSTALLLOCATION]$(var.ExeFile) / CustomAction Id=LaunchApplication BinaryKey=WixCA DllEntry=WixShellExec Impersonate=no / Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchApplication WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT Installed /Publish As you can see, it's almost identical to the original example code in Wix.chm. Anyways, I also run the installer and checked the log. Here's some log: MSI (c) (B8:D4) [11:44:33:697]: Decrementing counter to disable shutdown. If counter = 0, shutdown will be denied. Counter after decrement: -1 MSI (c) (B8:D4) [11:44:33:697]: PROPERTY CHANGE: Deleting SECONDSEQUENCE property. Its current value is '1'. Action ended 11:44:33: ExecuteAction. Return value 1. MSI (c) (B8:D4) [11:44:33:697]: Doing action: ExitDialog Action 11:44:33: ExitDialog. Action start 11:44:33: ExitDialog. Action 11:44:33: ExitDialog. Dialog created MSI (c) (B8:DC) [11:44:35:785]: Doing action: LaunchApplication Action 11:44:35: LaunchApplication. Action start 11:44:35: LaunchApplication. MSI (c) (B8:EC) [11:44:35:787]: Invoking remote custom action. DLL: C:\Users\UserA\AppData\Local\Temp\MSI8A32.tmp, Entrypoint: WixShellExec Action ended 11:44:36: LaunchApplication. Return value 1. Action ended 11:44:36: ExitDialog. Return value 1. Action ended 11:44:36: INSTALL. Return value 1. MSI (c) (B8:D4) [11:44:36:124]: Destroying RemoteAPI object. MSI (c) (B8:48) [11:44:36:124]: Custom Action Manager thread ending. So the question now is: is there a way to launch the application by giving the same Integrity Level as we start it from the system Start menu? Thanks a lot. From: Rob Mensching r...@robmensching.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Sat, February 19, 2011 9:26:54 AM Subject: Re: [WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application When is your custom action scheduled? On Fri, Feb 18, 2011 at 3:17 PM, little.forest little.for...@ymail.comwrote: We found a problem in Vista/Win7: If we launch the application from the installer for the fresh installation, the Integrity level is empty. The process is on the same level as explorer.exe. If we start the application from Start menu after the installation, the Integrity level is Medium(just like other applications). And the process is under explorer.exe. The question is, how to launch the application from installer to make it have Medium Integrity level. By the way, by using Process Explorer from SystemInternals and turning on the Integrity field, the Integrity level field will show up. The reason we ask this is because: we have a bug which seems related to this Integrity Level thing. If the app is started from the Start menu, things are fine. If the app is launched from the installer for the 1st time installation, some functionalities don't work. I tried to set the 'Impersonate' field to be 'no'. But it doesn't help. Here's our launch app code: Property Id=WixShellExecTarget Value=[INSTALLLOCATION]$(var.ExeFile) / CustomAction Id=LaunchApplication BinaryKey=WixCA DllEntry=WixShellExec Impersonate=no / Thanks in advance
Re: [WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application
Thanks Rob for your reply. Honestly, I'm not sure when the custom action is scheduled because I took the example(How To: Run the Installed Application After Setup) from Wix.chm. Here's our code: Property Id=WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT Value=!(loc.LaunchAppString) $(var.ApplicationName) / Property Id=WixShellExecTarget Value=[INSTALLLOCATION]$(var.ExeFile) / CustomAction Id=LaunchApplication BinaryKey=WixCA DllEntry=WixShellExec Impersonate=no / Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchApplication WIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT Installed /Publish As you can see, it's almost identical to the original example code in Wix.chm. Anyways, I also run the installer and checked the log. Here's some log: MSI (c) (B8:D4) [11:44:33:697]: Decrementing counter to disable shutdown. If counter = 0, shutdown will be denied. Counter after decrement: -1 MSI (c) (B8:D4) [11:44:33:697]: PROPERTY CHANGE: Deleting SECONDSEQUENCE property. Its current value is '1'. Action ended 11:44:33: ExecuteAction. Return value 1. MSI (c) (B8:D4) [11:44:33:697]: Doing action: ExitDialog Action 11:44:33: ExitDialog. Action start 11:44:33: ExitDialog. Action 11:44:33: ExitDialog. Dialog created MSI (c) (B8:DC) [11:44:35:785]: Doing action: LaunchApplication Action 11:44:35: LaunchApplication. Action start 11:44:35: LaunchApplication. MSI (c) (B8:EC) [11:44:35:787]: Invoking remote custom action. DLL: C:\Users\UserA\AppData\Local\Temp\MSI8A32.tmp, Entrypoint: WixShellExec Action ended 11:44:36: LaunchApplication. Return value 1. Action ended 11:44:36: ExitDialog. Return value 1. Action ended 11:44:36: INSTALL. Return value 1. MSI (c) (B8:D4) [11:44:36:124]: Destroying RemoteAPI object. MSI (c) (B8:48) [11:44:36:124]: Custom Action Manager thread ending. So the question now is: is there a way to launch the application by giving the same Integrity Level as we start it from the system Start menu? Thanks a lot. From: Rob Mensching r...@robmensching.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Sat, February 19, 2011 9:26:54 AM Subject: Re: [WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application When is your custom action scheduled? On Fri, Feb 18, 2011 at 3:17 PM, little.forest little.for...@ymail.comwrote: We found a problem in Vista/Win7: If we launch the application from the installer for the fresh installation, the Integrity level is empty. The process is on the same level as explorer.exe. If we start the application from Start menu after the installation, the Integrity level is Medium(just like other applications). And the process is under explorer.exe. The question is, how to launch the application from installer to make it have Medium Integrity level. By the way, by using Process Explorer from SystemInternals and turning on the Integrity field, the Integrity level field will show up. The reason we ask this is because: we have a bug which seems related to this Integrity Level thing. If the app is started from the Start menu, things are fine. If the app is launched from the installer for the 1st time installation, some functionalities don't work. I tried to set the 'Impersonate' field to be 'no'. But it doesn't help. Here's our launch app code: Property Id=WixShellExecTarget Value=[INSTALLLOCATION]$(var.ExeFile) / CustomAction Id=LaunchApplication BinaryKey=WixCA DllEntry=WixShellExec Impersonate=no / Thanks in advance. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Index, Search Analyze Logs and other IT data in Real-Time with Splunk Collect, index and harness all the fast moving IT data generated by your
[WiX-users] How to change the Windows Integrity level in Vista/Win7 when launching the application
We found a problem in Vista/Win7: If we launch the application from the installer for the fresh installation, the Integrity level is empty. The process is on the same level as explorer.exe. If we start the application from Start menu after the installation, the Integrity level is Medium(just like other applications). And the process is under explorer.exe. The question is, how to launch the application from installer to make it have Medium Integrity level. By the way, by using Process Explorer from SystemInternals and turning on the Integrity field, the Integrity level field will show up. The reason we ask this is because: we have a bug which seems related to this Integrity Level thing. If the app is started from the Start menu, things are fine. If the app is launched from the installer for the 1st time installation, some functionalities don't work. I tried to set the 'Impersonate' field to be 'no'. But it doesn't help. Here's our launch app code: Property Id=WixShellExecTarget Value=[INSTALLLOCATION]$(var.ExeFile) / CustomAction Id=LaunchApplication BinaryKey=WixCA DllEntry=WixShellExec Impersonate=no / Thanks in advance. -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to write conditions for 'Change' mode
I'm not sure if the email was sent correctly or not. Just resend it. ~~ Thanks Blair. It's in InstallExecuteSequence. And it's before InstallFinalize. Here's the code: CustomAction Id=DoDllRegistration FileKey=FileRegistrator ExeCommand=/r Execute=deferred Return=ignore HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom /InstallExecuteSequence Thanks. From: little.forest little.for...@ymail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Mon, December 13, 2010 3:24:19 PM Subject: Re: [WiX-users] How to write conditions for 'Change' mode Thanks Blair. It's in InstallExecuteSequence. And it's before InstallFinalize. Here's the code: CustomAction Id=DoDllRegistration FileKey=FileRegistrator ExeCommand=/r Execute=deferred Return=ignore HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom /InstallExecuteSequence Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, December 10, 2010 11:57:29 PM Subject: Re: [WiX-users] How to write conditions for 'Change' mode In what sequence is your custom action (execute, or ui)? Where in that sequence is it scheduled (before CostInitialize, after CostFinalize, before or after InstallInitialize, before or after InstallFinalize)? -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Friday, December 10, 2010 12:00 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to write conditions for 'Change' mode Hi Blair, Thanks for your reply. We'd like to detect whenever the user adds the feature XYZ. Basically, we have a component which is an Outlook plugin. During installation, the user can choose install it or not. If the user doesn't install it in initial install, then she can add it in Change mode. There is an old post about this(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Feature-h ow-to-reinstall-it-or-uninstall-it-alone-td5608464.html#a5608786 ). After enabling the Change button, the user can install the feature by hitting the Change button. But after that, the dll wasn't registered. From log, I learnt the CA is skipped. So I thought the condition wasn't correct. So I'd like to do the registration CA in Change mode, and of course, this happens only if the user really install the component. I thought there is some condition like (NOT Installed) OR (InstallMode = 'Change'). But there is no such thing. So is this correct? Or there should be some other decent solution? Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, December 10, 2010 9:57:26 AM Subject: Re: [WiX-users] How to write conditions for 'Change' mode What are you trying to do in change mode? Detect whenever the user adds Feature_XYZ? Or detect anytime it is either added or stays? It's hard to write conditions when you don't know the scenario. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, December 09, 2010 10:25 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to write conditions for 'Change' mode Hi all, We have a customaction: Custom Action=DoDllRegistration Before=InstallFinalize (Not Installed) AND (amp;Feature_XYZ = 3)/Custom This works in initial install, but not in 'Change' mode. From here(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/InstallMo de-Conditions-DON-T-work-td707286.html ), I learnt that there is no such standard property, and See Examples of Conditional Statement Syntax for how you should do it. So I googled and found this: http://wix.mindcapers.com/wiki/Conditional_Inner_Text. !-- Run on initial install, repair and minor upgrade -- Condition Message='Blah'COMPANYDIR AND NOT REMOVE ~= ALL/Condition Even if it doesn't say 'Change' mode, I still gave it a try. This statement seems working in 'Change' mode: Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom So the question is, is this the right thing to do? Is there any potential risk that could blow our current stuff? How to write the correct condition for initial install and 'Change' mode? Thanks! -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https
Re: [WiX-users] How to write conditions for 'Change' mode
Thanks Blair. It's in InstallExecuteSequence. And it's before InstallFinalize. Here's the code: CustomAction Id=DoDllRegistration FileKey=FileRegistrator ExeCommand=/r Execute=deferred Return=ignore HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom /InstallExecuteSequence Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, December 10, 2010 11:57:29 PM Subject: Re: [WiX-users] How to write conditions for 'Change' mode In what sequence is your custom action (execute, or ui)? Where in that sequence is it scheduled (before CostInitialize, after CostFinalize, before or after InstallInitialize, before or after InstallFinalize)? -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Friday, December 10, 2010 12:00 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to write conditions for 'Change' mode Hi Blair, Thanks for your reply. We'd like to detect whenever the user adds the feature XYZ. Basically, we have a component which is an Outlook plugin. During installation, the user can choose install it or not. If the user doesn't install it in initial install, then she can add it in Change mode. There is an old post about this(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Feature-h ow-to-reinstall-it-or-uninstall-it-alone-td5608464.html#a5608786 ). After enabling the Change button, the user can install the feature by hitting the Change button. But after that, the dll wasn't registered. From log, I learnt the CA is skipped. So I thought the condition wasn't correct. So I'd like to do the registration CA in Change mode, and of course, this happens only if the user really install the component. I thought there is some condition like (NOT Installed) OR (InstallMode = 'Change'). But there is no such thing. So is this correct? Or there should be some other decent solution? Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, December 10, 2010 9:57:26 AM Subject: Re: [WiX-users] How to write conditions for 'Change' mode What are you trying to do in change mode? Detect whenever the user adds Feature_XYZ? Or detect anytime it is either added or stays? It's hard to write conditions when you don't know the scenario. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, December 09, 2010 10:25 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to write conditions for 'Change' mode Hi all, We have a customaction: Custom Action=DoDllRegistration Before=InstallFinalize (Not Installed) AND (amp;Feature_XYZ = 3)/Custom This works in initial install, but not in 'Change' mode. From here(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/InstallMo de-Conditions-DON-T-work-td707286.html ), I learnt that there is no such standard property, and See Examples of Conditional Statement Syntax for how you should do it. So I googled and found this: http://wix.mindcapers.com/wiki/Conditional_Inner_Text. !-- Run on initial install, repair and minor upgrade -- Condition Message='Blah'COMPANYDIR AND NOT REMOVE ~= ALL/Condition Even if it doesn't say 'Change' mode, I still gave it a try. This statement seems working in 'Change' mode: Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom So the question is, is this the right thing to do? Is there any potential risk that could blow our current stuff? How to write the correct condition for initial install and 'Change' mode? Thanks! -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built
Re: [WiX-users] How to write conditions for 'Change' mode
Hi Blair, Thanks for your reply. We'd like to detect whenever the user adds the feature XYZ. Basically, we have a component which is an Outlook plugin. During installation, the user can choose install it or not. If the user doesn't install it in initial install, then she can add it in Change mode. There is an old post about this(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Feature-how-to-reinstall-it-or-uninstall-it-alone-td5608464.html#a5608786 ). After enabling the Change button, the user can install the feature by hitting the Change button. But after that, the dll wasn't registered. From log, I learnt the CA is skipped. So I thought the condition wasn't correct. So I'd like to do the registration CA in Change mode, and of course, this happens only if the user really install the component. I thought there is some condition like (NOT Installed) OR (InstallMode = 'Change'). But there is no such thing. So is this correct? Or there should be some other decent solution? Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, December 10, 2010 9:57:26 AM Subject: Re: [WiX-users] How to write conditions for 'Change' mode What are you trying to do in change mode? Detect whenever the user adds Feature_XYZ? Or detect anytime it is either added or stays? It's hard to write conditions when you don't know the scenario. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, December 09, 2010 10:25 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to write conditions for 'Change' mode Hi all, We have a customaction: Custom Action=DoDllRegistration Before=InstallFinalize (Not Installed) AND (amp;Feature_XYZ = 3)/Custom This works in initial install, but not in 'Change' mode. From here(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/InstallMo de-Conditions-DON-T-work-td707286.html ), I learnt that there is no such standard property, and See Examples of Conditional Statement Syntax for how you should do it. So I googled and found this: http://wix.mindcapers.com/wiki/Conditional_Inner_Text. !-- Run on initial install, repair and minor upgrade -- Condition Message='Blah'COMPANYDIR AND NOT REMOVE ~= ALL/Condition Even if it doesn't say 'Change' mode, I still gave it a try. This statement seems working in 'Change' mode: Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom So the question is, is this the right thing to do? Is there any potential risk that could blow our current stuff? How to write the correct condition for initial install and 'Change' mode? Thanks! -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to write conditions for 'Change' mode
Hi all, We have a customaction: Custom Action=DoDllRegistration Before=InstallFinalize (Not Installed) AND (amp;Feature_XYZ = 3)/Custom This works in initial install, but not in 'Change' mode. From here(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/InstallMode-Conditions-DON-T-work-td707286.html ), I learnt that there is no such standard property, and See Examples of Conditional Statement Syntax for how you should do it. So I googled and found this: http://wix.mindcapers.com/wiki/Conditional_Inner_Text. !-- Run on initial install, repair and minor upgrade -- Condition Message='Blah'COMPANYDIR AND NOT REMOVE ~= ALL/Condition Even if it doesn't say 'Change' mode, I still gave it a try. This statement seems working in 'Change' mode: Custom Action=DoDllRegistration Before=InstallFinalize (NOT REMOVE ~= ALL) AND (amp;Feature_XYZ = 3)/Custom So the question is, is this the right thing to do? Is there any potential risk that could blow our current stuff? How to write the correct condition for initial install and 'Change' mode? Thanks! -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to detect Outlook 2010 64Bit version
We need to detect if Outlook 2010 is installed. Here is the code: Property Id='QUERY_OUTLOOK_2010_REG' RegistrySearch Id='QueryOutlook2010Reg' Root='HKLM' Key='SOFTWARE\Microsoft\Office\14.0\Outlook\InstallRoot' Name='Path' Type='raw' / /Property The property is set if Outlook 2010 32Bit version is installed. But it doesn't work if Outlook 2010 64Bit version is installed. I did some comparison in real testing. If Outlook 2010 32Bit is installed, the registry is: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Outlook\InstallRoot If Outlook 2010 64Bit is installed, then the registry is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Outlook\InstallRoot As you can see, in our code, the entry 'SOFTWARE\Microsoft\Office\14.0\Outlook\InstallRoot' is used. I'm under the impression that Wix will automatically return the right registry without using Wow6432Node. It can detect 32bit version correctly, but why it can't detect correctly if 64bit is installed? Is it because our installer is 32 bit then it can't read 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft' entry? Is there a way to look both 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft' and 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft' entries explicitly? Thanks! -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to detect Outlook 2010 64Bit version
Never mind. I added these code, it seems working: Property Id='QUERY_OUTLOOK_2010_REG_64BIT' RegistrySearch Id='QueryOutlook2010Reg64Bit' Root='HKLM' Key='SOFTWARE\Microsoft\Office\14.0\Outlook\InstallRoot' Name='Path' Type='raw' Win64='yes' / /Property Thanks anyway. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Fri, November 5, 2010 3:32:25 PM Subject: [WiX-users] How to detect Outlook 2010 64Bit version We need to detect if Outlook 2010 is installed. Here is the code: Property Id='QUERY_OUTLOOK_2010_REG' RegistrySearch Id='QueryOutlook2010Reg' Root='HKLM' Key='SOFTWARE\Microsoft\Office\14.0\Outlook\InstallRoot' Name='Path' Type='raw' / /Property The property is set if Outlook 2010 32Bit version is installed. But it doesn't work if Outlook 2010 64Bit version is installed. I did some comparison in real testing. If Outlook 2010 32Bit is installed, the registry is: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Outlook\InstallRoot If Outlook 2010 64Bit is installed, then the registry is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Outlook\InstallRoot As you can see, in our code, the entry 'SOFTWARE\Microsoft\Office\14.0\Outlook\InstallRoot' is used. I'm under the impression that Wix will automatically return the right registry without using Wow6432Node. It can detect 32bit version correctly, but why it can't detect correctly if 64bit is installed? Is it because our installer is 32 bit then it can't read 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft' entry? Is there a way to look both 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft' and 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft' entries explicitly? Thanks! -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] FeatureTree: how to disable the feature selection ability if certain condition isn't met
We have a feature which is an Outlook plugin. Two questions - 1. We allow the end user to install the feature only if the user has Outlook 2007 or Outlook 2010. So I added some code to detect if Outlook is installed in target machine. Then when I installed it in a machine who doesn't have Outlook, I saw there is a 'X' mark on the feature itself. The feature is disabled. This is good. But the user can still change it to be Will be installed on local hard drive.. Is there a way to disable the feature selection? Such as, grey out the feature selection on GUI in this case? Here is my code: Feature Id='Feature_OutlookPlugin' AllowAdvertise='no' Description='!(loc.CustomMsgDesc)' Title='!(loc.CustomMsgTitle)' Level='2' Condition Level='1' FOUND_OUTLOOK2007 OR FOUND_OUTLOOK2010 /Condition blah.. blah... 2. We need to register a dll if the end user chooses to install the feature. If the user doesn't install the feature, then we shouldn't try to register the dll. I found a solution which seems working. But I'm not sure if it's the proper way to do it. Here is the code: Custom Action=DoDllRegistration Before=InstallFinalize (Not Installed) AND (amp;Feature_OutlookPlugin = 3)/Custom Is this correct? Thanks everyone. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Feature: how to reinstall it or uninstall it alone?
Hi, We added a feature in our installer. The feature is a plugin for Outlook. We defined a Feature element in our Wix file. We also integrated CustomizeDlg in our version of WixUI_InstallDir.wxs. Things work fine. Here are two more requirements: 1. If the end user chooses NOT to install this Outlook plugin feature in the 1st time installation, but later she wants to install the feature, is there a way for her to install it? I practiced the Repair mode, that feature selection tree didn't come out. So I have no chance to install the feature. How to do to give the end user a second chance to install the feature? 2. Is there a way for the end user to only uninstall the plugin feature but not the main application? How to do it? Right now, when uninstall, both the main application and the plugin feature will be gone. Thanks in advance! -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Feature: how to reinstall it or uninstall it alone?
Wow, that's fast. I appreciate that, Blair. I just made the code changes by following your instructions and did some basic testing. It works fine. We'll do more testing. Thanks again, Blair! From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, October 6, 2010 12:28:23 PM Subject: Re: [WiX-users] Feature: how to reinstall it or uninstall it alone? You need to make the maintenancetype dialog send the changebutton to the customize dialog in your version of wixui_installdir. Also, ARPNOMODIFY should NOT be defined. Change can be used to both add and remove features without removing the entire product. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Wednesday, October 06, 2010 12:13 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Feature: how to reinstall it or uninstall it alone? Hi, We added a feature in our installer. The feature is a plugin for Outlook. We defined a Feature element in our Wix file. We also integrated CustomizeDlg in our version of WixUI_InstallDir.wxs. Things work fine. Here are two more requirements: 1. If the end user chooses NOT to install this Outlook plugin feature in the 1st time installation, but later she wants to install the feature, is there a way for her to install it? I practiced the Repair mode, that feature selection tree didn't come out. So I have no chance to install the feature. How to do to give the end user a second chance to install the feature? 2. Is there a way for the end user to only uninstall the plugin feature but not the main application? How to do it? Right now, when uninstall, both the main application and the plugin feature will be gone. Thanks in advance! -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to change to a directory and run customaction inside that directory?
Hi all, We have an urgent issue. We install some 3rd party files. After installing, we need to run its registration program. It's something like this: adxreg.exe /install=myapp.dll The problem is, this 3rd party adxreg.exe command doesn't support path. So this doesn't work: C:\Program Files\Common Files\MyApp\adxreg.exe /install=C:\Program Files\Common Files\MyApp\myapp.dll We have to change directory to C:\Program Files\Common Files\MyApp\ first and then run adxreg.exe /install=myapp.dll. How to do it in Wix? Here is my code: Component Id='Component_Adxregistrator' Guid='*' File Id='AdxRegistrator' Name='adxreg.exe' Source='adxregistrator.exe' KeyPath=yes Checksum=yes / /Component CustomAction Id=DoDllRegistration FileKey=AdxRegistrator ExeCommand=/install=MyApp.dll /privileges=admin Execute=deferred Return=ignore HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=DoDllRegistration Before=InstallFinalize Not Installed/Custom /InstallExecuteSequence Here is log: Action 12:58:52: DoDllRegistration. MSI (s) (68:24) [12:58:52:669]: Executing op: CustomActionSchedule(Action=DoDllRegistration,ActionType=3154,Source=C:\Program Files\Common Files\MyApp\adxreg.exe,Target=/install=MyApp.dll /privileges=admin,) MSI (s) (68:24) [12:58:53:403]: Executing op: End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=62406035) MSI (s) (68:24) [12:58:53:419]: User policy value 'DisableRollback' is 0 MSI (s) (68:24) [12:58:53:419]: Machine policy value 'DisableRollback' is 0 Action 12:58:53: RollbackCleanup. Removing backup files Thanks. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to change to a directory and run customaction inside that directory?
Thanks Sohail.
If anybody knows how to fix this, please tell me. Thanks in advance.
I don't know how to use batch file in customaction.
But I
found
http://blogs.technet.com/b/alexshev/archive/2008/02/21/from-msi-to-wix-part-5-custom-actions.aspx.
Even Rob said it's not
good(http://wix.sourceforge.net/manual-wix2/robmen_20040520.htm ), I just want
to get something working today. We need to ship something tonight.
Anyway, I found type 22(vbscript) maybe the one we need. So I tried it. But it
doesn't work for me.
I mean, the vbscript itself works, here it is:
Public Function Main()
Dim WshShell
Set WshShell = WScript.CreateObject(WScript.Shell)
WshShell.CurrentDirectory = C:\Program Files\Common Files\MyApp
WshShell.Run adxreg.exe /install=myapp.dll
Set WshShell = Nothing
End Function
Main
This works fine if I just run it. But if I include it in code it doesn't work:
Component Id=Component_TFR Guid=*
File Id='File_Fix' Name='fix.vbs' Source=fix.vbs
KeyPath=yes Checksum=yes/
/Component
CustomAction Id=DoDllRegistration
FileKey=File_Tfr
VBScriptCall=Main
Execute=deferred
Return=ignore
HideTarget=no
Impersonate=no /
InstallExecuteSequence
Custom Action=DoDllRegistration Before=InstallFinalize Not
Installed/Custom
/InstallExecuteSequence
Here is log:
Action 16:08:42: DoDllRegistration.
MSI (s) (34:A8) [16:08:42:070]: Executing op:
CustomActionSchedule(Action=DoDllRegistration,ActionType=3158,Source=C:\Program
Files\MyApp\tfr.vbs,Target=Main,)
MSI (s) (34:CC) [16:08:42:070]: Generating random cookie.
MSI (s) (34:CC) [16:08:42:086]: Created Custom Action Server with PID 3296
(0xCE0).
MSI (s) (34:54) [16:08:42:148]: Running as a service.
MSI (s) (34:94) [16:08:42:148]: Hello, I'm your 32bit Elevated custom action
server.
MSI (s) (34:30) [16:08:42:148]: Entering MsiProvideComponentFromDescriptor.
Descriptor: ,igp...@+@w'iRd7tcotMainAppM5KDYSUnf(HA*L[xeX)y, PathBuf: BEF348,
pcchPathBuf: BEF344, pcchArgsOffset: BEF29C
MSI (s) (34:30) [16:08:42:148]: MsiProvideComponentFromDescriptor called for
component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded
oleaut32.dll value
MSI (s) (34:30) [16:08:42:148]: MsiProvideComponentFromDescriptor is returning:
0
MSI (s) (34:30) [16:08:42:164]: Note: 1: 1720 2: DoDllRegistration 3:
-2146827864 4: Microsoft VBScript runtime error 5: Object required: 'WScript'
6:
3 7: 2
Info 1720. There is a problem with this Windows Installer package. A script
required for this install to complete could not be run. Contact your support
personnel or package vendor. Custom action DoDllRegistration script error
-2146827864, Microsoft VBScript runtime error: Object required: 'WScript' Line
3, Column 2,
MSI (s) (34:A8) [16:08:42:164]: Executing op:
End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=63735264)
MSI (s) (34:A8) [16:08:42:179]: User policy value 'DisableRollback' is 0
MSI (s) (34:A8) [16:08:42:179]: Machine policy value 'DisableRollback' is 0
Action 16:08:42: RollbackCleanup. Removing backup files
Why it's okay if I run it manually but not work in Wix? For the 'WScript'
error,
MS has examples: http://msdn.microsoft.com/en-us/library/d5fk67ky(VS.85).aspx
From: Sohail Somani soh...@taggedtype.net
To: wix-users@lists.sourceforge.net
Sent: Fri, September 10, 2010 4:00:36 PM
Subject: Re: [WiX-users] How to change to a directory and run customaction
inside that directory?
On 10-09-10 4:31 PM, little.forest wrote:
We have to change directory to C:\Program Files\Common Files\MyApp\ first
and
then run adxreg.exe /install=myapp.dll. How to do it in Wix?
You can do it in a batch file and pass it [INSTALLDIR] in the ExeCommand
(iirc). So something like:
CustomAction ... ExeCommand=[INSTALLDIR]\batchfile.bat ...
The batch file can use %~dp0 to change to the installdirectory first.
--
Sohail Somani
--
iBlog : http://uint32t.blogspot.com
iTweet: http://twitter.com/somanisoftware
iCode : http://bitbucket.org/cheez
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to change to a directory and run customaction inside that directory?
Thanks Edwin! Yes, I also found it in here(http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg12592.html ). It works now. But some people said using vbscript in customaction isn't a good idea. so what could be the best solution if not using vbscript? Thanks. From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, September 10, 2010 5:50:03 PM Subject: Re: [WiX-users] How to change to a directory and run customaction inside that directory? Try: Public Function Main() Dim WshShell Set WshShell = CreateObject(WScript.Shell) WshShell.CurrentDirectory = C:\Program Files\Common Files\MyApp WshShell.Run adxreg.exe /install=myapp.dll Set WshShell = Nothing End Function Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: little.forest [mailto:little.for...@ymail.com] Anyway, I found type 22(vbscript) maybe the one we need. So I tried it. But it doesn't work for me. I mean, the vbscript itself works, here it is: Public Function Main() Dim WshShell Set WshShell = WScript.CreateObject(WScript.Shell) WshShell.CurrentDirectory = C:\Program Files\Common Files\MyApp WshShell.Run adxreg.exe /install=myapp.dll Set WshShell = Nothing End Function Main -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to change to a directory and run customaction inside that directory?
Thanks Christopher. I appreciate it. I looked at that manual. I actually implemented type 18 customaction in the first place. But it didn't work for us. Here is my original code: Component Id='Component_Adxregistrator' Guid='*' File Id='AdxRegistrator' Name='adxreg.exe' Source='adxregistrator.exe' KeyPath=yes Checksum=yes / /Component CustomAction Id=DoDllRegistration FileKey=AdxRegistrator ExeCommand=/install=MyApp.dll /privileges=admin Execute=deferred Return=ignore HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=DoDllRegistration Before=InstallFinalize Not Installed/Custom /InstallExecuteSequence The problem isn't about Wix. The problem is that 3rd party program. It doesn't support path in the executable name. So things like C:\Program Files\adxreg.exe /install doesn't work. You have to actually in that folder and run adxreg.exe /install. This is really odd to me. And you're correct that thing is a home-made SelfReg. The program is from Addin Express. So I wonder if there is a better way to actually change dir to the folder, and then run adxreg.exe /install from there. If you know there is a way, let me know please. From: Christopher Painter chr...@deploymentengineering.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, September 10, 2010 7:28:40 PM Subject: Re: [WiX-users] How to change to a directory and run customaction inside that directory? VBScript is unacceptable for installs that I write. Have you looked at http://wix.sourceforge.net/manual-wix3/qtexec.htm to see if it meets your needs? BTW, the commandline being called in this example suggests to me additional problems with this installers design. adxreg.exe /install=myapp.dll sounds a lot like a home grown SelfReg pattern which brings all sorts of other problems. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: little.forest little.for...@ymail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, September 10, 2010 9:21:05 PM Subject: Re: [WiX-users] How to change to a directory and run customaction inside that directory? Thanks Edwin! Yes, I also found it in here(http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg12592.html ). It works now. But some people said using vbscript in customaction isn't a good idea. so what could be the best solution if not using vbscript? Thanks. From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, September 10, 2010 5:50:03 PM Subject: Re: [WiX-users] How to change to a directory and run customaction inside that directory? Try: Public Function Main() Dim WshShell Set WshShell = CreateObject(WScript.Shell) WshShell.CurrentDirectory = C:\Program Files\Common Files\MyApp WshShell.Run adxreg.exe /install=myapp.dll Set WshShell = Nothing End Function Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: little.forest [mailto:little.for...@ymail.com] Anyway, I found type 22(vbscript) maybe the one we need. So I tried it. But it doesn't work for me. I mean, the vbscript itself works, here it is: Public Function Main() Dim WshShell Set WshShell = WScript.CreateObject(WScript.Shell) WshShell.CurrentDirectory = C:\Program Files\Common Files\MyApp WshShell.Run adxreg.exe /install=myapp.dll Set WshShell = Nothing End Function Main -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment
Re: [WiX-users] Wix 2.0: how to change popup wording
Thanks Palbinder. Good to know it's supported in 5.0. From: Pally Sandher pally.sand...@iesve.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tue, August 24, 2010 2:07:33 AM Subject: Re: [WiX-users] Wix 2.0: how to change popup wording 1 - not without forcing your package to be Windows Installer 5.0 only. Windows Installer 5.0 is only available on Windows 7, there's no redistributables for any earlier versions of Windows. If you're happy with that, knock yourself out. 2 - see above. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: 23 August 2010 23:34 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 2.0: how to change popup wording We have an urgent issue. One of our old app using Wix 2.0. This app is an Outlook plugin. So the app needs the Outlook shutdown before installing. So we added a detect-and-report CustomAction in the installer long while ago. Here is the code: Binary Id=CheckOutlook_Dll SourceFile=checkOL.dll / CustomAction Id=CheckOutlookRunningCA BinaryKey=CheckOutlook_Dll DllEntry=CheckOL / CustomAction Id=RefuseRunningCA Error=Please close Outlook before installing. / InstallUISequence Custom Action=CheckOutlookRunningCA Before=CostFinalize / Custom Action=RefuseRunningCA After=CostFinalizeNOT Installed AND ShowProgramRunDialog = 1/Custom /InstallUISequence This worked fine. But now we want to change it. 1. Now it is an Error type of CustomAction. Is it possible to add a clickable hyperlink in the dialog text? 2. We'd like to change the wording of the last page, now it says YourApp Setup Wizard ended prematurely blah blah. I know we can change FatalErrorTitle, FatalErrorDescription1 and FatalErrorDescription2. Is it possible to add some clickable hyperlink in these text? Thanks! -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to debug CustomAction DLL
Dear Wix Experts: We have a CustomAction DLL written in C. How to debug it? There are a few posts about it: Post1: http://www.davidmoore.info/2010/06/28/how-to-debug-a-windows-installer-custom-action/ Post2: http://blogs.msdn.com/b/astebner/archive/2005/06/17/430320.aspx Post3: http://msdn.microsoft.com/en-us/library/aa368264(VS.85).aspx I tried it in Windows 7. I did set MsiBreak, but that famous message box never showed up. So I tried it in XP, the message box showed up. It says To debug your custom action, attach your debugger to process 5632(0x1600) and press OK. I opened Windbg. Post1 says attach the process, Post2 says Open Executable I tried both, neither works for me. In both cases, I got *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll - ntdll!DbgBreakPoint: 7c90120e cc int 3 in Windbg. Questions: 1. What's the problem here? 2. Should I attach process? Or should I Open Executable...? 3. If I should attach process, why it doesn't work? 4. If I should Open Executable..., what the File name and Arguments fields should be? For example, the File name should be C:\Temp\MyApp.msi or C:\Windows\system32\msiexec.exe? How about arguments? Should it be /i C:\Temp\MyApp.msi? 5. Why it doesn't work in Windows 7? If you even debug DLL CustomAction, pls let me know. Thanks! -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix 2.0: how to change popup wording
We have an urgent issue. One of our old app using Wix 2.0. This app is an Outlook plugin. So the app needs the Outlook shutdown before installing. So we added a detect-and-report CustomAction in the installer long while ago. Here is the code: Binary Id=CheckOutlook_Dll SourceFile=checkOL.dll / CustomAction Id=CheckOutlookRunningCA BinaryKey=CheckOutlook_Dll DllEntry=CheckOL / CustomAction Id=RefuseRunningCA Error=Please close Outlook before installing. / InstallUISequence Custom Action=CheckOutlookRunningCA Before=CostFinalize / Custom Action=RefuseRunningCA After=CostFinalizeNOT Installed AND ShowProgramRunDialog = 1/Custom /InstallUISequence This worked fine. But now we want to change it. 1. Now it is an Error type of CustomAction. Is it possible to add a clickable hyperlink in the dialog text? 2. We'd like to change the wording of the last page, now it says YourApp Setup Wizard ended prematurely blah blah. I know we can change FatalErrorTitle, FatalErrorDescription1 and FatalErrorDescription2. Is it possible to add some clickable hyperlink in these text? Thanks! -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to add FeatureTree
Hi all, We need to add a new feature. I tried to add WixUI_FeatureTree. But I got compile errors saying that I have duplicated in ControlEvent. The reason is that I already have WixUI_InstallDir in UIRef. How can I add WixUI_FeatureTree and don't have these compile errors? Is it possible to add just the feature page instead of adding the whole WixUI_InstallDir UIRef? Thanks in advance. From: little.forest little.for...@ymail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 2:08:03 PM Subject: Re: [WiX-users] How to add FeatureTree Thanks Chris. You already helped me moving to the right direction, I guess. If anyone know the solution, please let me know. From: Chris Lord chris.l...@atterotech.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 1:54:24 PM Subject: Re: [WiX-users] How to add FeatureTree Sadly, you are getting to the extent of my knowledge and experience here so I am not sure I can offer much more advice. What you need is to take your customized version of WixUI_InstallDir and add to it the useful dialogs from WixUI_FeatureTree. Unfortunately, how best to achieve that I do not know. Chris On 08/11/2010 04:23 PM, little.forest wrote: Thanks Chris. I removed MyWixUI_InstallDir which is the copy of WixUI_InstallDir with some changes. I got it compile and run. But some problems: 1. The change install dir page is gone. But we need it back. 2. We added a dialog called MyAddedConfirmDlg between InstallDirDlg and VerifyReadyDlg. If we found some user's settings need to be upgraded then we show this MyAddedConfirmDlg to let the end user decide to upgrade the settings or not. This MyAddedConfirmDlg was added in the MyWixUI_InstallDir.wxs file. Where can I add my own MyAddedConfirmDlg? 3. I didn't test all cases, are there maybe other potential problems? Thanks. From: Chris Lordchris.l...@atterotech.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 12:56:27 PM Subject: Re: [WiX-users] How to add FeatureTree I suspect your original UI refs contain a welcome dialog. The FeatureTree UI is a complete UI. Its not just a FeatureTree dialog so the combination of your UIrefs and FeatureTree means you have duplicate dialogs, hence the error. If the standard feature tree UI sequence work for you as is, then remove your other UIrefs and just use FeatureTree on its own. If you use a custom UI sequence then your only option, I think, is to add the individual dialogs you need to your custom UI. You won't be able to use WixUI_FeatureTree as is. Chris On 08/11/2010 03:28 PM, little.forest wrote: Hi Chris, Thanks. Yes, I have UIRef before I added the new FeatureTree: UIRef Id=MyWixUI_InstallDir/ UIRef Id=WixUI_ErrorProgressText/ From: Chris Lordchris.l...@atterotech.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 12:22:40 PM Subject: Re: [WiX-users] How to add FeatureTree Did you already have a UIRef in your wxs before you added the FeatureTree UIRef? On 08/11/2010 03:00 PM, little.forest wrote: We'll need to add a new component. And we'd like the end user to choose to install it or not. I found the FeatureTree maybe a fit for us. So I add these code: UIRef Id=WixUI_FeatureTree/ Property Id=INSTALL_FEATURE1 Value=1 / DirectoryRef Id='INSTALLLOCATION' Component Id='COMP_FTR1' Guid='*' File Source='feature1.dll' KeyPath=yes Checksum=yes / /Component /DirectoryRef Feature Id='Feature_1' AllowAdvertise='no' Description='This is for feature 1' Title='New feature 1' Level='2' Condition Level='1'INSTALL_FEATURE1/Condition ComponentRef Id='COMP_FTR1' / /Feature But I'm getting this error when compiling: error LGHT0130 : The primary key 'LicenseAgreementDlg/Back/NewDialog/WelcomeDlg/1' is duplicated in table 'ControlEvent'. Please remove one of the entries or rename a part of the primary key to avoid the collision. How can I fix it? Thanks all. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net
[WiX-users] How to add FeatureTree
We'll need to add a new component. And we'd like the end user to choose to install it or not. I found the FeatureTree maybe a fit for us. So I add these code: UIRef Id=WixUI_FeatureTree/ Property Id=INSTALL_FEATURE1 Value=1 / DirectoryRef Id='INSTALLLOCATION' Component Id='COMP_FTR1' Guid='*' File Source='feature1.dll' KeyPath=yes Checksum=yes / /Component /DirectoryRef Feature Id='Feature_1' AllowAdvertise='no' Description='This is for feature 1' Title='New feature 1' Level='2' Condition Level='1'INSTALL_FEATURE1/Condition ComponentRef Id='COMP_FTR1' / /Feature But I'm getting this error when compiling: error LGHT0130 : The primary key 'LicenseAgreementDlg/Back/NewDialog/WelcomeDlg/1' is duplicated in table 'ControlEvent'. Please remove one of the entries or rename a part of the primary key to avoid the collision. How can I fix it? Thanks all. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to add FeatureTree
Hi Chris, Thanks. Yes, I have UIRef before I added the new FeatureTree: UIRef Id=MyWixUI_InstallDir/ UIRef Id=WixUI_ErrorProgressText/ From: Chris Lord chris.l...@atterotech.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 12:22:40 PM Subject: Re: [WiX-users] How to add FeatureTree Did you already have a UIRef in your wxs before you added the FeatureTree UIRef? On 08/11/2010 03:00 PM, little.forest wrote: We'll need to add a new component. And we'd like the end user to choose to install it or not. I found the FeatureTree maybe a fit for us. So I add these code: UIRef Id=WixUI_FeatureTree/ Property Id=INSTALL_FEATURE1 Value=1 / DirectoryRef Id='INSTALLLOCATION' Component Id='COMP_FTR1' Guid='*' File Source='feature1.dll' KeyPath=yes Checksum=yes / /Component /DirectoryRef Feature Id='Feature_1' AllowAdvertise='no' Description='This is for feature 1' Title='New feature 1' Level='2' Condition Level='1'INSTALL_FEATURE1/Condition ComponentRef Id='COMP_FTR1' / /Feature But I'm getting this error when compiling: error LGHT0130 : The primary key 'LicenseAgreementDlg/Back/NewDialog/WelcomeDlg/1' is duplicated in table 'ControlEvent'. Please remove one of the entries or rename a part of the primary key to avoid the collision. How can I fix it? Thanks all. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to add FeatureTree
Thanks Chris. I removed MyWixUI_InstallDir which is the copy of WixUI_InstallDir with some changes. I got it compile and run. But some problems: 1. The change install dir page is gone. But we need it back. 2. We added a dialog called MyAddedConfirmDlg between InstallDirDlg and VerifyReadyDlg. If we found some user's settings need to be upgraded then we show this MyAddedConfirmDlg to let the end user decide to upgrade the settings or not. This MyAddedConfirmDlg was added in the MyWixUI_InstallDir.wxs file. Where can I add my own MyAddedConfirmDlg? 3. I didn't test all cases, are there maybe other potential problems? Thanks. From: Chris Lord chris.l...@atterotech.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 12:56:27 PM Subject: Re: [WiX-users] How to add FeatureTree I suspect your original UI refs contain a welcome dialog. The FeatureTree UI is a complete UI. Its not just a FeatureTree dialog so the combination of your UIrefs and FeatureTree means you have duplicate dialogs, hence the error. If the standard feature tree UI sequence work for you as is, then remove your other UIrefs and just use FeatureTree on its own. If you use a custom UI sequence then your only option, I think, is to add the individual dialogs you need to your custom UI. You won't be able to use WixUI_FeatureTree as is. Chris On 08/11/2010 03:28 PM, little.forest wrote: Hi Chris, Thanks. Yes, I have UIRef before I added the new FeatureTree: UIRef Id=MyWixUI_InstallDir/ UIRef Id=WixUI_ErrorProgressText/ From: Chris Lordchris.l...@atterotech.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 12:22:40 PM Subject: Re: [WiX-users] How to add FeatureTree Did you already have a UIRef in your wxs before you added the FeatureTree UIRef? On 08/11/2010 03:00 PM, little.forest wrote: We'll need to add a new component. And we'd like the end user to choose to install it or not. I found the FeatureTree maybe a fit for us. So I add these code: UIRef Id=WixUI_FeatureTree/ Property Id=INSTALL_FEATURE1 Value=1 / DirectoryRef Id='INSTALLLOCATION' Component Id='COMP_FTR1' Guid='*' File Source='feature1.dll' KeyPath=yes Checksum=yes / /Component /DirectoryRef Feature Id='Feature_1' AllowAdvertise='no' Description='This is for feature 1' Title='New feature 1' Level='2' Condition Level='1'INSTALL_FEATURE1/Condition ComponentRef Id='COMP_FTR1' / /Feature But I'm getting this error when compiling: error LGHT0130 : The primary key 'LicenseAgreementDlg/Back/NewDialog/WelcomeDlg/1' is duplicated in table 'ControlEvent'. Please remove one of the entries or rename a part of the primary key to avoid the collision. How can I fix it? Thanks all. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to add FeatureTree
Thanks Chris. You already helped me moving to the right direction, I guess. If anyone know the solution, please let me know. From: Chris Lord chris.l...@atterotech.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 1:54:24 PM Subject: Re: [WiX-users] How to add FeatureTree Sadly, you are getting to the extent of my knowledge and experience here so I am not sure I can offer much more advice. What you need is to take your customized version of WixUI_InstallDir and add to it the useful dialogs from WixUI_FeatureTree. Unfortunately, how best to achieve that I do not know. Chris On 08/11/2010 04:23 PM, little.forest wrote: Thanks Chris. I removed MyWixUI_InstallDir which is the copy of WixUI_InstallDir with some changes. I got it compile and run. But some problems: 1. The change install dir page is gone. But we need it back. 2. We added a dialog called MyAddedConfirmDlg between InstallDirDlg and VerifyReadyDlg. If we found some user's settings need to be upgraded then we show this MyAddedConfirmDlg to let the end user decide to upgrade the settings or not. This MyAddedConfirmDlg was added in the MyWixUI_InstallDir.wxs file. Where can I add my own MyAddedConfirmDlg? 3. I didn't test all cases, are there maybe other potential problems? Thanks. From: Chris Lordchris.l...@atterotech.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 12:56:27 PM Subject: Re: [WiX-users] How to add FeatureTree I suspect your original UI refs contain a welcome dialog. The FeatureTree UI is a complete UI. Its not just a FeatureTree dialog so the combination of your UIrefs and FeatureTree means you have duplicate dialogs, hence the error. If the standard feature tree UI sequence work for you as is, then remove your other UIrefs and just use FeatureTree on its own. If you use a custom UI sequence then your only option, I think, is to add the individual dialogs you need to your custom UI. You won't be able to use WixUI_FeatureTree as is. Chris On 08/11/2010 03:28 PM, little.forest wrote: Hi Chris, Thanks. Yes, I have UIRef before I added the new FeatureTree: UIRef Id=MyWixUI_InstallDir/ UIRef Id=WixUI_ErrorProgressText/ From: Chris Lordchris.l...@atterotech.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 11, 2010 12:22:40 PM Subject: Re: [WiX-users] How to add FeatureTree Did you already have a UIRef in your wxs before you added the FeatureTree UIRef? On 08/11/2010 03:00 PM, little.forest wrote: We'll need to add a new component. And we'd like the end user to choose to install it or not. I found the FeatureTree maybe a fit for us. So I add these code: UIRef Id=WixUI_FeatureTree/ Property Id=INSTALL_FEATURE1 Value=1 / DirectoryRef Id='INSTALLLOCATION' Component Id='COMP_FTR1' Guid='*' File Source='feature1.dll' KeyPath=yes Checksum=yes / /Component /DirectoryRef Feature Id='Feature_1' AllowAdvertise='no' Description='This is for feature 1' Title='New feature 1' Level='2' Condition Level='1'INSTALL_FEATURE1/Condition ComponentRef Id='COMP_FTR1' / /Feature But I'm getting this error when compiling: error LGHT0130 : The primary key 'LicenseAgreementDlg/Back/NewDialog/WelcomeDlg/1' is duplicated in table 'ControlEvent'. Please remove one of the entries or rename a part of the primary key to avoid the collision. How can I fix it? Thanks all. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] .NET 4 and Wix 3.5
We're migrating our app to use .NET 4.0. We'll need to detect and install .NET 4.0. We're using Wix 3.0. From this post(http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NetFxExtension-and-NET-4-td4969906.html#a4969906 ), it seems we need to move to Wix 3.5. But I tried to install Wix 3.5 - it replaced the version 3.0. This is a problem: in our build server, we installed Wix 3.0 already. If 3.5 replaces 3.0, our old builds cannot be built because they can't find the 3.0 compiler(the path thing). Is there a way that 3.0 and 3.5 co-exist in one machine? If yes, how to do it? If not, is it possible to install 3.5 in one machine, and then copy the candle/light stuff over to some other machine and use it? In another word, Wix 3.5 must be installed to run(needs some registry or system stuff be there)? Or it can run like a portable application? Thanks! -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to copy registry subkey which includes some entries
Thanks Palbinder. It's good to know the VersionNT64 property. It's sad to learn I've to do it the long way. From: Pally Sandher pally.sand...@iesve.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 4, 2010 3:39:46 AM Subject: Re: [WiX-users] How to copy registry subkey which includes some entries 1 - http://msdn.microsoft.com/en-us/library/aa372497.aspx 2 - Nope you'll have to do it the long way. You'll need 2 MSI's if you want to access the 64-bit areas of the registry on x64 platforms. MSI's are platform architecture specific. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: 04 August 2010 01:28 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to copy registry subkey which includes some entries We need to do these: 1. Detect the HKCU\Software\CompanyX\ProductY key(this key includes 5 entries) in registry, if the key exists, then copy it to be HKCU\Software\CompanyX\ProductY_Fix. 2. For 32 bit machine, detect if HKLM\Software\CompanyX\ProductY exists. If it exists, then copy the key to be HKLM\Software\CompanyX\ProductY_Fix. 3. For 64 bit machine, detect if HKLM\Software\Wow6432Node\CompanyX\ProductY exists. If it exists, then copy the key to be HKLM\Software\Wow6432Node\CompanyX\ProductY_Fix. I have a couple of questions: 1. How to detect if the target machine is 32 bit or 64 bit? 2. The ProductY key includes 5 entries, is there any easy way to copy the whole key instead of doing it one by one entry? I know a way to it for one entry: - detect the new key - if it doesn't exist, then query the old key, and then create the new key Property Id='QUERY_PRODUCTY_LIB' RegistrySearch Id='QueryProductYKey' Root='HKCU' Key='Software\CompanyX\ProductY' Name='lib' Type='raw' / /Property Property Id='DETECT_PRODUCTY_FIX' RegistrySearch Id='DetectProductYFix' Root='HKCU' Key='Software\CompanyX\ProductY_Fix' Type='raw' / /Property Component Id=WriteRegKey Guid=* ConditionNOT DETECT_PRODUCTY_FIX and QUERY_PRODUCTY_LIB ''/Condition RegistryKey Root=HKCU Key=Software\CompanyX\ProductY_Fix Action=create RegistryValue Type=string Name='lib' Value='[QUERY_PRODUCTY_LIB]' KeyPath=yes / /RegistryKey /Component ComponentRef Id=WriteRegKey / So is there an easy way that I can do it for the whole key once? Otherwise, I'll have to repeat these 25 lines of code multiple times. That is really error-prone. Based on the requirements we have, I'd think we'll have to end with 375 lines of coce((5+5+5) x 25 = 375) to deal with HKCU, HKLM, and HKLM\Software\Wow6432Node. But really, they are really identical code except the key entries are different such as 'lib', 'network', or 'key' etc. If there is a way to do it easily, please let me know. Also I'm stuck on how to detect if the machine is 32 bit or 64 bit. Many thanks. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to copy registry subkey which includes someentries
Thanks David. I'm gonna try the HKLM in my 64 bit machine. From: David Watson dwat...@sdl.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 4, 2010 3:55:33 AM Subject: Re: [WiX-users] How to copy registry subkey which includes someentries Hi, It looks like you will only need to do the HKLM code once, if you write it for the 32 bit version and your msi is 32 bit it will automatically be redirected by windows to the Wow6432Node on 64 bit operating systems. As for the easy way sadly there is none if you don't want to write a custom action. Dave -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 04 August 2010 11:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to copy registry subkey which includes someentries 1 - http://msdn.microsoft.com/en-us/library/aa372497.aspx 2 - Nope you'll have to do it the long way. You'll need 2 MSI's if you want to access the 64-bit areas of the registry on x64 platforms. MSI's are platform architecture specific. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: 04 August 2010 01:28 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to copy registry subkey which includes some entries We need to do these: 1. Detect the HKCU\Software\CompanyX\ProductY key(this key includes 5 entries) in registry, if the key exists, then copy it to be HKCU\Software\CompanyX\ProductY_Fix. 2. For 32 bit machine, detect if HKLM\Software\CompanyX\ProductY exists. If it exists, then copy the key to be HKLM\Software\CompanyX\ProductY_Fix. 3. For 64 bit machine, detect if HKLM\Software\Wow6432Node\CompanyX\ProductY exists. If it exists, then copy the key to be HKLM\Software\Wow6432Node\CompanyX\ProductY_Fix. I have a couple of questions: 1. How to detect if the target machine is 32 bit or 64 bit? 2. The ProductY key includes 5 entries, is there any easy way to copy the whole key instead of doing it one by one entry? I know a way to it for one entry: - detect the new key - if it doesn't exist, then query the old key, and then create the new key Property Id='QUERY_PRODUCTY_LIB' RegistrySearch Id='QueryProductYKey' Root='HKCU' Key='Software\CompanyX\ProductY' Name='lib' Type='raw' / /Property Property Id='DETECT_PRODUCTY_FIX' RegistrySearch Id='DetectProductYFix' Root='HKCU' Key='Software\CompanyX\ProductY_Fix' Type='raw' / /Property Component Id=WriteRegKey Guid=* ConditionNOT DETECT_PRODUCTY_FIX and QUERY_PRODUCTY_LIB ''/Condition RegistryKey Root=HKCU Key=Software\CompanyX\ProductY_Fix Action=create RegistryValue Type=string Name='lib' Value='[QUERY_PRODUCTY_LIB]' KeyPath=yes / /RegistryKey /Component ComponentRef Id=WriteRegKey / So is there an easy way that I can do it for the whole key once? Otherwise, I'll have to repeat these 25 lines of code multiple times. That is really error-prone. Based on the requirements we have, I'd think we'll have to end with 375 lines of coce((5+5+5) x 25 = 375) to deal with HKCU, HKLM, and HKLM\Software\Wow6432Node. But really, they are really identical code except the key entries are different such as 'lib', 'network', or 'key' etc. If there is a way to do it easily, please let me know. Also I'm stuck on how to detect if the machine is 32 bit or 64 bit. Many thanks. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users /pre BR style=font-size:4px; a href = http://www.sdl.com;img src=http://www.sdl.com/images/emaillogo_150dpi-01.png; alt=www.sdl.com border=0/ BR font face=arial size=2 a href = http://www.sdl.com; style=color:005740; font-weight: boldwww.sdl.com BR BR font
Re: [WiX-users] How to copy registry subkey which includes someentries
Thanks Blair. I never used foreach.. I'll try that. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 4, 2010 7:54:22 AM Subject: Re: [WiX-users] How to copy registry subkey which includes someentries As to the long way, you may find using the ?for? preprocessor construct helpful to ease the code maintenance required. -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Wednesday, August 04, 2010 3:56 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to copy registry subkey which includes someentries Hi, It looks like you will only need to do the HKLM code once, if you write it for the 32 bit version and your msi is 32 bit it will automatically be redirected by windows to the Wow6432Node on 64 bit operating systems. As for the easy way sadly there is none if you don't want to write a custom action. Dave -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 04 August 2010 11:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to copy registry subkey which includes someentries 1 - http://msdn.microsoft.com/en-us/library/aa372497.aspx 2 - Nope you'll have to do it the long way. You'll need 2 MSI's if you want to access the 64-bit areas of the registry on x64 platforms. MSI's are platform architecture specific. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: 04 August 2010 01:28 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to copy registry subkey which includes some entries We need to do these: 1. Detect the HKCU\Software\CompanyX\ProductY key(this key includes 5 entries) in registry, if the key exists, then copy it to be HKCU\Software\CompanyX\ProductY_Fix. 2. For 32 bit machine, detect if HKLM\Software\CompanyX\ProductY exists. If it exists, then copy the key to be HKLM\Software\CompanyX\ProductY_Fix. 3. For 64 bit machine, detect if HKLM\Software\Wow6432Node\CompanyX\ProductY exists. If it exists, then copy the key to be HKLM\Software\Wow6432Node\CompanyX\ProductY_Fix. I have a couple of questions: 1. How to detect if the target machine is 32 bit or 64 bit? 2. The ProductY key includes 5 entries, is there any easy way to copy the whole key instead of doing it one by one entry? I know a way to it for one entry: - detect the new key - if it doesn't exist, then query the old key, and then create the new key Property Id='QUERY_PRODUCTY_LIB' RegistrySearch Id='QueryProductYKey' Root='HKCU' Key='Software\CompanyX\ProductY' Name='lib' Type='raw' / /Property Property Id='DETECT_PRODUCTY_FIX' RegistrySearch Id='DetectProductYFix' Root='HKCU' Key='Software\CompanyX\ProductY_Fix' Type='raw' / /Property Component Id=WriteRegKey Guid=* ConditionNOT DETECT_PRODUCTY_FIX and QUERY_PRODUCTY_LIB ''/Condition RegistryKey Root=HKCU Key=Software\CompanyX\ProductY_Fix Action=create RegistryValue Type=string Name='lib' Value='[QUERY_PRODUCTY_LIB]' KeyPath=yes / /RegistryKey /Component ComponentRef Id=WriteRegKey / So is there an easy way that I can do it for the whole key once? Otherwise, I'll have to repeat these 25 lines of code multiple times. That is really error-prone. Based on the requirements we have, I'd think we'll have to end with 375 lines of coce((5+5+5) x 25 = 375) to deal with HKCU, HKLM, and HKLM\Software\Wow6432Node. But really, they are really identical code except the key entries are different such as 'lib', 'network', or 'key' etc. If there is a way to do it easily, please let me know. Also I'm stuck on how to detect if the machine is 32 bit or 64 bit. Many thanks. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users
[WiX-users] FileInUse doesn't work in XP?
Our QA found an issue: during uninstallation, if our app is minimized in systray, the FileInUse dialog doesn't show up. That will cause crash when the end user tries to activate and run the app - as the app is already uninstalled. I tried it, in Windows 7, it works fine - I did see the FileInUse dialog showing up. But in XP, the FileInUse dialog didn't show. I found this post: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/FileInUse-and-MsiRMFilesInUse-dialogs-td4430290.html#a4430934 Does it mean the FileInUse doesn't work in XP is the expected behavior? If so, is there anything I could do to make it work in XP? Our QA(and PM) is after me for this issue. I own them an explanation. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FileInUse doesn't work in XP?
Thanks Travis for your reply. Yes, we tried CloseApplication, but it doesn't help. From: Travis Gaff tra...@pc-doctor.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 4, 2010 2:08:07 PM Subject: Re: [WiX-users] FileInUse doesn't work in XP? I think we found similar issues. The RMFilesInUse behavior is different in XP vs. Windows 7 and possibly in Vista as well. We ended up adding several custom actions to try to stop our executables both with and without elevation. You can try the WiX util:CloseApplication to get started, but we found that it wasn't sufficiently aggressive in stopping our application. Travis -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Wednesday, August 04, 2010 1:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FileInUse doesn't work in XP? Our QA found an issue: during uninstallation, if our app is minimized in systray, the FileInUse dialog doesn't show up. That will cause crash when the end user tries to activate and run the app - as the app is already uninstalled. I tried it, in Windows 7, it works fine - I did see the FileInUse dialog showing up. But in XP, the FileInUse dialog didn't show. I found this post: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/FileInUse-an d-MsiRMFilesInUse-dialogs-td4430290.html#a4430934 Does it mean the FileInUse doesn't work in XP is the expected behavior? If so, is there anything I could do to make it work in XP? Our QA(and PM) is after me for this issue. I own them an explanation. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FileInUse doesn't work in XP?
Thanks Phil. That's what I explained to our team. So now, our team agreed that we can look for a solution in future. From: Wilson, Phil phil.wil...@invensys.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, August 4, 2010 2:08:32 PM Subject: Re: [WiX-users] FileInUse doesn't work in XP? It's expected because Windows 7 MSI engine has a better detection mechanism (Restart Manager) for files in use. Prior to that it wouldn't detect apps minimized in the system tray. Maybe WiX's close apps custom action would help. Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Wednesday, August 04, 2010 1:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FileInUse doesn't work in XP? Our QA found an issue: during uninstallation, if our app is minimized in systray, the FileInUse dialog doesn't show up. That will cause crash when the end user tries to activate and run the app - as the app is already uninstalled. I tried it, in Windows 7, it works fine - I did see the FileInUse dialog showing up. But in XP, the FileInUse dialog didn't show. I found this post: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/FileInUse-and-MsiRMFilesInUse-dialogs-td4430290.html#a4430934 Does it mean the FileInUse doesn't work in XP is the expected behavior? If so, is there anything I could do to make it work in XP? Our QA(and PM) is after me for this issue. I own them an explanation. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to copy registry subkey which includes some entries
We need to do these: 1. Detect the HKCU\Software\CompanyX\ProductY key(this key includes 5 entries) in registry, if the key exists, then copy it to be HKCU\Software\CompanyX\ProductY_Fix. 2. For 32 bit machine, detect if HKLM\Software\CompanyX\ProductY exists. If it exists, then copy the key to be HKLM\Software\CompanyX\ProductY_Fix. 3. For 64 bit machine, detect if HKLM\Software\Wow6432Node\CompanyX\ProductY exists. If it exists, then copy the key to be HKLM\Software\Wow6432Node\CompanyX\ProductY_Fix. I have a couple of questions: 1. How to detect if the target machine is 32 bit or 64 bit? 2. The ProductY key includes 5 entries, is there any easy way to copy the whole key instead of doing it one by one entry? I know a way to it for one entry: - detect the new key - if it doesn't exist, then query the old key, and then create the new key Property Id='QUERY_PRODUCTY_LIB' RegistrySearch Id='QueryProductYKey' Root='HKCU' Key='Software\CompanyX\ProductY' Name='lib' Type='raw' / /Property Property Id='DETECT_PRODUCTY_FIX' RegistrySearch Id='DetectProductYFix' Root='HKCU' Key='Software\CompanyX\ProductY_Fix' Type='raw' / /Property Component Id=WriteRegKey Guid=* ConditionNOT DETECT_PRODUCTY_FIX and QUERY_PRODUCTY_LIB ''/Condition RegistryKey Root=HKCU Key=Software\CompanyX\ProductY_Fix Action=create RegistryValue Type=string Name='lib' Value='[QUERY_PRODUCTY_LIB]' KeyPath=yes / /RegistryKey /Component ComponentRef Id=WriteRegKey / So is there an easy way that I can do it for the whole key once? Otherwise, I'll have to repeat these 25 lines of code multiple times. That is really error-prone. Based on the requirements we have, I'd think we'll have to end with 375 lines of coce((5+5+5) x 25 = 375) to deal with HKCU, HKLM, and HKLM\Software\Wow6432Node. But really, they are really identical code except the key entries are different such as 'lib', 'network', or 'key' etc. If there is a way to do it easily, please let me know. Also I'm stuck on how to detect if the machine is 32 bit or 64 bit. Many thanks. -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to install a component to make it work for multiple builds
We're going to implement a plugin for Microsoft Outlook. We'll include this plugin in our MSI installer. First of all, we OEM our software. That means, for example, the customerA has their own installer which may include 15 features; the customerB has their own installer which may include 20 features. If we treat this Outlook plugin as one of the existing features, life will be easier. We just need to add the plugin, give it a GUID, and the plugin will be installed in the same folder as any other components. But now, the requirement for this Outlook plugin is, to make this plugin serve for multiple builds. It means, all customer builds share one plugin. If the new version of the build is installed(no matter customerA, or customerB, or customerC), then the build should update this shared plugin version if the new build has the most updated version. Right now, the customer's build is installed in the folder like Program Files\CustomerA. I can imagine, this plugin has to be installed in a common folder such as Program Files\Common\My Company\Outlook Plugin. How can I do that? As you know, customerA and customerB installers have different package ID. How these different installers can control one component? By the way, we support Major Upgrade in our installer for all customers. Thanks. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix doesn't recognize USB drive or other removable storage
We use Wix 3.0. Some of our customers complain that the installer doesn't recognize USB drive or other removable storage when installing. So basically, in Destination Folder page, the end user tried to change the install folder to a USB drive. But there is no USB drive showing up in drop-down list. When the end user tried to change the folder from Folder name: field, she got an error says: Installation directory must be on a local hard drive. I did some research and found this is not a Wix limitation, but MSI's. So my questions are: 1. Is there a way to get rid of it? I think it makes sense to allow the end user to install the software on their portable devices. 2. What's the purpose of this limitation? Security? I understand this is probably MSI's limitation. But if you happen to know the reason, please help me understand it. Thanks! -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditions for Uninstall/Remove Only
Thanks Sanjay. This is great. Especially there is a table - much clearer. From: Sanjay Rao s...@noida.interrasystems.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, March 31, 2010 11:02:18 PM Subject: Re: [WiX-users] Conditions for Uninstall/Remove Only try out this one. (NOT UPGRADINGPRODUCTCODE) AND (REMOVE=ALL) for more details u can see http://stackoverflow.com/questions/320921/how-to-add-a-wix-custom-action-that-happens-only-on-uninstall-via-msi -Sanjay little.forest wrote: How can I create conditions for a custom action to run for Uninstall/Remove only? If I use condition 'Installed' then the CA runs in Repair mode. If I use condition 'Remove=ALL' then the CA doesn't run in Repair, but it doesn't run in Uninstall/Remove either. Thanks. __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
Thanks Bob, You're right. They don't support MSI. From: Bob Arnson b...@joyofsetup.com To: wix-users@lists.sourceforge.net Sent: Wed, March 31, 2010 5:22:35 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode On 3/31/2010 2:31 PM, little.forest wrote: Actually we asked the vendor first, but they told us sorry, we don't support Wix... They don't have to support WiX, just MSI. -- sig://boB http://joyofsetup.com/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
Thanks Dave. I'll try that. From: Dave Brotherstone dav...@pobox.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tue, March 30, 2010 10:42:16 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode On Wed, Mar 31, 2010 at 1:39 AM, little.forest little.for...@ymail.comwrote: Hi All, I totally understand 'using regsvr32 in Wix' is not recommended. But in this adxloader.dll case, we can't use tallow or heat to generate fragments from the dll. This is not the problem of tallow or heat, but the problem of the dll. However, the dll can be registered manually by using regsvr32.exe. So my question is: is there a way that we can collect the needed registry information manually? If it's possible, then we can get rid of regsvr32. You can probably see the registry entries manually by watching regsvr32 in procmon (from sysinternals). You'll need to convert the output to WiX, but at least you'll see everything that is written. Just set the filter to procname=regsvr32, and only watch the registry. Dave. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
Thanks Palbinder. Actually we asked the vendor first, but they told us sorry, we don't support Wix... Anyways, here I have another question about the conditions: 1. What is the conditions if I'd like to run the custom action in both 'fresh install' and 'Repair'? Is there something like this? - Not Installed OR Repair=1 2. What is the conditions if I'd like to fun the custom action in 'uninstallation' only? Is this correct? - Remove=ALL 3. Also, What's the condition for 'fresh install' only? For the 2nd one, it doesn't work. Well, the custom action didn't run in 'fresh install' or 'Repair', but it didn't run in 'Uninstallation/Remove', either. What is the correct condition for that case? Thanks. From: Pally Sandher pally.sand...@iesve.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, March 31, 2010 3:38:43 AM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode RegSpy2 may be able to help. See http://www.installsite.org/pages/en/msi/tips.htm about 1/3 down the page. It'll output a .reg file which you run through tallow.exe to output WiX code. However I would ask the vendor of this adxloader.dll for support first. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Dave Brotherstone [mailto:dav...@pobox.com] Sent: 31 March 2010 06:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted,then we'll get Error 2836 in Repair mode On Wed, Mar 31, 2010 at 1:39 AM, little.forest little.for...@ymail.comwrote: Hi All, I totally understand 'using regsvr32 in Wix' is not recommended. But in this adxloader.dll case, we can't use tallow or heat to generate fragments from the dll. This is not the problem of tallow or heat, but the problem of the dll. However, the dll can be registered manually by using regsvr32.exe. So my question is: is there a way that we can collect the needed registry information manually? If it's possible, then we can get rid of regsvr32. You can probably see the registry entries manually by watching regsvr32 in procmon (from sysinternals). You'll need to convert the output to WiX, but at least you'll see everything that is written. Just set the filter to procname=regsvr32, and only watch the registry. Dave. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Conditions for Uninstall/Remove Only
How can I create conditions for a custom action to run for Uninstall/Remove only? If I use condition 'Installed' then the CA runs in Repair mode. If I use condition 'Remove=ALL' then the CA doesn't run in Repair, but it doesn't run in Uninstall/Remove either. Thanks. __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditions for Uninstall/Remove Only
Thanks Phil! That works. Sorry, I didn't pay attention on that. From: Wilson, Phil phil.wil...@invensys.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, March 31, 2010 4:17:59 PM Subject: Re: [WiX-users] Conditions for Uninstall/Remove Only That's because property names are case sensitive and the actual name is REMOVE. Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Wednesday, March 31, 2010 3:55 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Conditions for Uninstall/Remove Only How can I create conditions for a custom action to run for Uninstall/Remove only? If I use condition 'Installed' then the CA runs in Repair mode. If I use condition 'Remove=ALL' then the CA doesn't run in Repair, but it doesn't run in Uninstall/Remove either. Thanks. __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What does Repair do?
Thanks Don! Those are some great info. From: Don Pratt don.pr...@cox.net To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tue, March 30, 2010 8:55:19 AM Subject: Re: [WiX-users] What does Repair do? Hi little.forrest, I can't answer your question (what does repair do) directly, but here's how I'd find out. The first step is to turn on logging for windows installer. You can either do this when you run the MSI (assuming you're directly running the MSI file, not using control panel) or use a registry setting to turn on logging globally. See http://support.microsoft.com/kb/223300 for details. After you turn on logging, do a repair operation and go look at the log to see what specific actions it took. IF you're brave, you can just open the log file in Notepad. I prefer to use the log file analyzer that Microsoft provides in the Windows SDK (http://msdn.microsoft.com/en-us/library/aa372811%28VS.85%29.aspx). It still takes some thinking to figure out what's happening. Maybe start by clicking the States button to see the feature and component states. Hope this helps, Don Pratt little.forest wrote: Just a general question: what does Repair do? I know Repairs errors in the most recent installation by fixing missing and corrupt files, shortcuts, and registry entries. But odd something happened. We have a product which uses Wix 2.0. The product is a plugin for Microsoft Outlook. If we just install it, it seems fine. But after that, if we re-install it in Repair mode, then Outlook will crash after the Repair. I checked the log of the Wix. Everything seems fine - Configuration completed successfully.. I also checked the application event viewer. It just says Outlook crash, nothing useful. So what does Repair normally do? Is there way to figure out what's going on? And what kind of thing caused Outlook crash? Thanks a lot. __ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What does Repair do?
Thanks Phil. Yes, it seems a custom action unregistered a dll during Repair. From: Wilson, Phil phil.wil...@invensys.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tue, March 30, 2010 11:54:04 AM Subject: Re: [WiX-users] What does Repair do? It goes through each component and checks that its KeyPath is present and correct. In your case, I suspect that some custom action is running, maybe some code that re-installs the add-in or tries to shut down Outlook. Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Monday, March 29, 2010 5:48 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What does Repair do? Just a general question: what does Repair do? I know Repairs errors in the most recent installation by fixing missing and corrupt files, shortcuts, and registry entries. But odd something happened. We have a product which uses Wix 2.0. The product is a plugin for Microsoft Outlook. If we just install it, it seems fine. But after that, if we re-install it in Repair mode, then Outlook will crash after the Repair. I checked the log of the Wix. Everything seems fine - Configuration completed successfully.. I also checked the application event viewer. It just says Outlook crash, nothing useful. So what does Repair normally do? Is there way to figure out what's going on? And what kind of thing caused Outlook crash? Thanks a lot. __ The new Internet Explorer(r) 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
Hi All, Allow me to recap this issue please. Basically, we have an old product(uses Wix 2.0) that is an Outlook plugin application. We use a COM component adxloader.dll from Add-in Express(http://www.add-in-express.com/) in the product. What we need to do is to install the adxloader.dll and register it as a COM. But unfortunately, adxloader isn't friendly for Wix. By using tallow or heat, we can't generate the correct fragments from it. But somebody gives us a solution: http://blogs.microsoft.co.il/blogs/yanush/archive/2008/09/22/howto-use-regsvr32-exe-with-wix.aspx It is kind of working. But there are two problems: 1. After installation, if we re-run the installer and choose Repair. Then Outlook will crash when we start it. This is because these statements: CustomAction Id=RegisterAdx Directory=INSTALLDIR ExeCommand='regsvr32.exe /s [INSTALLDIR]adxloader.dll' Return=check /CustomAction CustomAction Id=UnregisterAdx Directory=INSTALLDIR ExeCommand='regsvr32.exe /s /u [INSTALLDIR]adxloader.dll' /CustomAction InstallExecuteSequence Custom Action=RegisterAdx After=InstallFinalizeNOT Installed/Custom Custom Action=UnregisterAdx Before=InstallInitializeInstalled/Custom /InstallExecuteSequence As what you can see, during Repair, the dll will be unregistered. If the dll isn't registered, then Outlook will crash. So I changed the condition to make sure we only unregister the dll in uninstall or remove: Custom Action=UnregisterAdx Before=InstallInitializeRemove=ALL/Custom This seems working. 2. Out QA also tested this case which is failed: after installation, delete the adxloader.dll, and run the installer again and choose Repair - the result is that the adxloader.dll never comes back and throws a 'Error 2836'. I think this is related to #1. The reason is because in Repair, the installer will try to unregister the file, and couldn't find the file. By fixing #1, this problem seems gone. Right now, it seems working. I totally understand 'using regsvr32 in Wix' is not recommended. But in this adxloader.dll case, we can't use tallow or heat to generate fragments from the dll. This is not the problem of tallow or heat, but the problem of the dll. However, the dll can be registered manually by using regsvr32.exe. So my question is: is there a way that we can collect the needed registry information manually? If it's possible, then we can get rid of regsvr32. Please let me know. I appreciate it. From: little.forest little.for...@ymail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Mon, March 29, 2010 5:35:29 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode Thanks Chad. Actually I tried that, but I got some errors: Microsoft (R) Windows Installer Xml Tool version 2.0.5325.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Fragment DirectoryRef Id=TARGETDIR Component Id=component0 DiskId=1 Guid=PUT-GUID-HERE File Id=file0 Name=ADXLOA_1.DLL LongName=adxloader.dll Source=C:\mydir\adxloader.dll /Failed to SelfReg: adxloader.dll System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --- System.TypeInitializationException: Type constructor threw an exception. at DllRegisterServer() --- End of inner exception stack trace --- at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct sig, MethodAttrib utes methodAttributes, RuntimeTypeHandle typeOwner) at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes met hodAttributes, RuntimeTypeHandle typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters , CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters , CultureInfo culture) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain.DynamicPInvoke(String dll, String entryPoint, Type ret urnType, Type[] parameterTypes, Object[] parameterValues) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain..ctor(String[] args) Registry Root=HKCU Key=Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders Name=Personal / Registry Root=HKCU Key=Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders / /Component /DirectoryRef /Fragment /Wix From: Chad Petersen chad.peter...@harlandfs.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Mon, March 29, 2010 2:40:07 PM Subject: Re: [WiX-users] Wix 2.0
Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
Thanks Bob. That dll is provided by a 3rd party company. We don't know how it's implemented. But I guess something isn't quite right with the DLL. We'll try to talk to the dll provider to understand the detail. The dll can be registered correctly by using regsvr32.exe. So after using regsvr32.exe, is there a way that we could manually collect the registry info for the dll and then use them in the installer? Thanks. From: Bob Arnson b...@joyofsetup.com To: wix-users@lists.sourceforge.net Sent: Sat, March 27, 2010 12:06:31 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode On 3/26/2010 2:12 PM, little.forest wrote: 2. Those two DLL files will cause 'Error 2836' directly. But the manifest file will cause the installer showing 'The system can not find the file specified.' first then showing the 'Error 2836'. So this is slightly different from those two DLL files. As I mentioned, that's not a fatal error. There's some other error that might be helpful in diagnosing your root problem. 1. If my guess is correct, please post some links here about how to register a COM component correctly in 2.0. Meanwhile, I'll dig in this topic as well. Use Class, Interface, ProgId, Extension, Verb, TypeLib. -- sig://boB http://joyofsetup.com/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
Thanks Chad. Actually I tried that, but I got some errors: Microsoft (R) Windows Installer Xml Tool version 2.0.5325.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Fragment DirectoryRef Id=TARGETDIR Component Id=component0 DiskId=1 Guid=PUT-GUID-HERE File Id=file0 Name=ADXLOA_1.DLL LongName=adxloader.dll Source=C:\mydir\adxloader.dll /Failed to SelfReg: adxloader.dll System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. --- System.TypeInitializationException: Type constructor threw an exception. at DllRegisterServer() --- End of inner exception stack trace --- at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct sig, MethodAttrib utes methodAttributes, RuntimeTypeHandle typeOwner) at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes met hodAttributes, RuntimeTypeHandle typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters , CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters , CultureInfo culture) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain.DynamicPInvoke(String dll, String entryPoint, Type ret urnType, Type[] parameterTypes, Object[] parameterValues) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain..ctor(String[] args) Registry Root=HKCU Key=Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders Name=Personal / Registry Root=HKCU Key=Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders / /Component /DirectoryRef /Fragment /Wix From: Chad Petersen chad.peter...@harlandfs.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Mon, March 29, 2010 2:40:07 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode Look at the Tallow.exe utility. I think Tallow -s filename might be a first step to try. Chad -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Monday, March 29, 2010 2:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted,then we'll get Error 2836 in Repair mode Thanks Bob. That dll is provided by a 3rd party company. We don't know how it's implemented. But I guess something isn't quite right with the DLL. We'll try to talk to the dll provider to understand the detail. The dll can be registered correctly by using regsvr32.exe. So after using regsvr32.exe, is there a way that we could manually collect the registry info for the dll and then use them in the installer? Thanks. From: Bob Arnson b...@joyofsetup.com To: wix-users@lists.sourceforge.net Sent: Sat, March 27, 2010 12:06:31 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode On 3/26/2010 2:12 PM, little.forest wrote: 2. Those two DLL files will cause 'Error 2836' directly. But the manifest file will cause the installer showing 'The system can not find the file specified.' first then showing the 'Error 2836'. So this is slightly different from those two DLL files. As I mentioned, that's not a fatal error. There's some other error that might be helpful in diagnosing your root problem. 1. If my guess is correct, please post some links here about how to register a COM component correctly in 2.0. Meanwhile, I'll dig in this topic as well. Use Class, Interface, ProgId, Extension, Verb, TypeLib. -- sig://boB http://joyofsetup.com/ -- Download Intel(r) Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users
[WiX-users] What does Repair do?
Just a general question: what does Repair do? I know Repairs errors in the most recent installation by fixing missing and corrupt files, shortcuts, and registry entries. But odd something happened. We have a product which uses Wix 2.0. The product is a plugin for Microsoft Outlook. If we just install it, it seems fine. But after that, if we re-install it in Repair mode, then Outlook will crash after the Repair. I checked the log of the Wix. Everything seems fine - Configuration completed successfully.. I also checked the application event viewer. It just says Outlook crash, nothing useful. So what does Repair normally do? Is there way to figure out what's going on? And what kind of thing caused Outlook crash? Thanks a lot. __ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
First of all, thank you so much for your reply, Bob. There are a couple of other things, not sure if related: 1. Only 3 files cause the problem. According to the developer, one dll file is a COM component, the manifest is associated with the COM dll, another dll is used by the COM dll. I also noticed the COM dll is registered by using regsvr32.exe in a custom action. Not sure if this is the problem. But I've a feeling that COM registration doesn't work that way even I never register a COM in Wix. 2. Those two DLL files will cause 'Error 2836' directly. But the manifest file will cause the installer showing 'The system can not find the file specified.' first then showing the 'Error 2836'. So this is slightly different from those two DLL files. 3. I did look at the dll files' property, they seem normal. By using Orca, I also looked at the File table, these files entries look the same as others. From #1, my guess is the COM registration could cause the problem, but I'm not sure. Please point out if my guess is correct or not: 1. If my guess is correct, please post some links here about how to register a COM component correctly in 2.0. Meanwhile, I'll dig in this topic as well. 2. If my guess isn't correct, please point me out where I should look into, or which file or flag or something I should check. Thanks a lot. From: Bob Arnson b...@joyofsetup.com To: wix-users@lists.sourceforge.net Sent: Thu, March 25, 2010 5:58:55 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode On 3/25/2010 7:53 PM, little.forest wrote: DEBUG: Error 2836: The control ChangeButton on the dialog MaintenanceTypeDlg can not take focus The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2836. The arguments are: MaintenanceTypeDlg, ChangeButton, That's not a fatal error; is there some other symptom you're seeing? -- sig://boB http://joyofsetup.com/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
Thanks Palbinder. I'll try tallow. From: Pally Sandher pally.sand...@iesve.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, March 26, 2010 11:26:09 AM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode Tallow.exe in WiX v2.0 should be able to harvest the registry entries required for COM registration (assuming the DLL exports DLLRegisterServer function). Tallow.exe is with the WiX v2.0 equivalent of heat.exe in WiX v3.0. I don't have a WiX v2.0 install lying around but running tallow.exe /? should give you the parameters needed to harvest the COM registration info. Sounds like the problem is the Self Reg of the COM DLL. If one of the 2 DLL's or the manifest file is deleted it may not be able to re-run the Self Reg when you run your repair as it may not have replaced the files at that point. Yet another reason why Self-Reg is a very very very bad idea. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: 26 March 2010 18:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted,then we'll get Error 2836 in Repair mode First of all, thank you so much for your reply, Bob. There are a couple of other things, not sure if related: 1. Only 3 files cause the problem. According to the developer, one dll file is a COM component, the manifest is associated with the COM dll, another dll is used by the COM dll. I also noticed the COM dll is registered by using regsvr32.exe in a custom action. Not sure if this is the problem. But I've a feeling that COM registration doesn't work that way even I never register a COM in Wix. 2. Those two DLL files will cause 'Error 2836' directly. But the manifest file will cause the installer showing 'The system can not find the file specified.' first then showing the 'Error 2836'. So this is slightly different from those two DLL files. 3. I did look at the dll files' property, they seem normal. By using Orca, I also looked at the File table, these files entries look the same as others. From #1, my guess is the COM registration could cause the problem, but I'm not sure. Please point out if my guess is correct or not: 1. If my guess is correct, please post some links here about how to register a COM component correctly in 2.0. Meanwhile, I'll dig in this topic as well. 2. If my guess isn't correct, please point me out where I should look into, or which file or flag or something I should check. Thanks a lot. From: Bob Arnson b...@joyofsetup.com To: wix-users@lists.sourceforge.net Sent: Thu, March 25, 2010 5:58:55 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode On 3/25/2010 7:53 PM, little.forest wrote: DEBUG: Error 2836: The control ChangeButton on the dialog MaintenanceTypeDlg can not take focus The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2836. The arguments are: MaintenanceTypeDlg, ChangeButton, That's not a fatal error; is there some other symptom you're seeing? -- sig://boB http://joyofsetup.com/ -- Download Intel(r) Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
OK, I tried tallow. But it doesn't work. First, I tried tallow.exe -c my.dll, but I got System.BadImageFormatException. Then I tried tallow.exe -s my.dll, but I got System.Reflection.TargetInvocationException. I also tried heat from 3.0 heat.exe file my.dll -out my.wxs, but I only got this: Fragment DirectoryRef Id=mydir FileSource=C:\mydir Component Id=my.dll Guid=PUT-GUID-HERE File Id=my.dll Name=my.dll KeyPath=yes Source=C:\mydir\my.dll / /Component /DirectoryRef /Fragment There is no any COM related info there. Help please. I appreciate it. From: little.forest little.for...@ymail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, March 26, 2010 3:25:42 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode Thanks Palbinder. I'll try tallow. From: Pally Sandher pally.sand...@iesve.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, March 26, 2010 11:26:09 AM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode Tallow.exe in WiX v2.0 should be able to harvest the registry entries required for COM registration (assuming the DLL exports DLLRegisterServer function). Tallow.exe is with the WiX v2.0 equivalent of heat.exe in WiX v3.0. I don't have a WiX v2.0 install lying around but running tallow.exe /? should give you the parameters needed to harvest the COM registration info. Sounds like the problem is the Self Reg of the COM DLL. If one of the 2 DLL's or the manifest file is deleted it may not be able to re-run the Self Reg when you run your repair as it may not have replaced the files at that point. Yet another reason why Self-Reg is a very very very bad idea. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: 26 March 2010 18:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted,then we'll get Error 2836 in Repair mode First of all, thank you so much for your reply, Bob. There are a couple of other things, not sure if related: 1. Only 3 files cause the problem. According to the developer, one dll file is a COM component, the manifest is associated with the COM dll, another dll is used by the COM dll. I also noticed the COM dll is registered by using regsvr32.exe in a custom action. Not sure if this is the problem. But I've a feeling that COM registration doesn't work that way even I never register a COM in Wix. 2. Those two DLL files will cause 'Error 2836' directly. But the manifest file will cause the installer showing 'The system can not find the file specified.' first then showing the 'Error 2836'. So this is slightly different from those two DLL files. 3. I did look at the dll files' property, they seem normal. By using Orca, I also looked at the File table, these files entries look the same as others. From #1, my guess is the COM registration could cause the problem, but I'm not sure. Please point out if my guess is correct or not: 1. If my guess is correct, please post some links here about how to register a COM component correctly in 2.0. Meanwhile, I'll dig in this topic as well. 2. If my guess isn't correct, please point me out where I should look into, or which file or flag or something I should check. Thanks a lot. From: Bob Arnson b...@joyofsetup.com To: wix-users@lists.sourceforge.net Sent: Thu, March 25, 2010 5:58:55 PM Subject: Re: [WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode On 3/25/2010 7:53 PM, little.forest wrote: DEBUG: Error 2836: The control ChangeButton on the dialog MaintenanceTypeDlg can not take focus The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2836. The arguments are: MaintenanceTypeDlg, ChangeButton, That's not a fatal error; is there some other symptom you're seeing? -- sig://boB http://joyofsetup.com/ -- Download Intel(r) Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
[WiX-users] Wix 2.0: if some dll file(s) deleted, then we'll get Error 2836 in Repair mode
We have an old product which uses Wix 2.0(a very stable version). Our test engineer found a problem: if some dll file(s) is manually deleted, then in Repair mode, we'll get Error 2836. Here is the error message from log: MSI (c) (B4:80) [16:22:22:313]: Note: 1: 2205 2: 3: Error MSI (c) (B4:80) [16:22:22:313]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2836 DEBUG: Error 2836: The control ChangeButton on the dialog MaintenanceTypeDlg can not take focus The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2836. The arguments are: MaintenanceTypeDlg, ChangeButton, In real case, I'd say no one would manually delete some files. But it could happen. Also as a test case, I think it's reasonable to test this scenario. And I thought, we're allowed to delete any file, then in Repair mode, we'll get all of our files back, correct? The strange thing is that it only happens for three files, not for all. If we delete some other files, Repair will work correctly. But I looked those files, they are really normal. I also check the msi in Orca. In the File table, they have normal attributes just like others. What make these files special? Is there a way to check what is wrong? Why removing a dll will cause something wrong in ChangeButton? I know 2.0 isn't supported any more. But for us, this old product is still using it. So if you know something, please let us know. Many thanks! __ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install on Windows 7: minimize the installation wizard, then only see a slice of the install page when finished
Yeah, that looks like something about the snap feature. Thanks Phil. From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, January 20, 2010 4:20:41 PM Subject: Re: [WiX-users] Install on Windows 7: minimize the installation wizard, then only see a slice of the install page when finished I thought this was a Windows 7 thing, part of the snap feature? Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Wednesday, January 20, 2010 2:42 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Install on Windows 7: minimize the installation wizard, then only see a slice of the install page when finished So I suppose this is a problem for all MSIs? Can anyone confirm it? Personally I don't think this is a big problem. But any small issue is a P1 issue in our team. :-) So I own them an explanation. Thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Fri, January 15, 2010 3:48:07 PM Subject: Install on Windows 7: minimize the installation wizard, then only see a slice of the install page when finished Here is the problem(our QA found it): In Windows 7, install the build. When the installation starts, minimize the installation wizard. When the installation finished, the install wizard shows on the top-left of the screen. We can only see a slice of the install wizard(the close button X shows on the top-left). I have to hit the button Alt to call the system menu and hit Move to move the screen to the center of the screen to see the whole install page. Why is that? I also tried the Wix installer itself in Windows 7. It's the same thing. By the way, in XP, it works fine. I mean, I minimized it, after finished, the install page popup and shows in the center of the screen. I suspect this is the problem from MSI. But I'm not sure. Let me know if you know the reason and how to fix it. It might not be that a big deal, but I'd like to know. Thanks. Make your browsing faster, safer, and easier with the new Internet Explorer(r) 8. Optimized for Yahoo! Get it Now for Free! __ Make your browsing faster, safer, and easier with the new Internet Explorer(r) 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install on Windows 7: minimize the installation wizard, then only see a slice of the install page when finished
So I suppose this is a problem for all MSIs? Can anyone confirm it? Personally I don't think this is a big problem. But any small issue is a P1 issue in our team. :-) So I own them an explanation. Thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Fri, January 15, 2010 3:48:07 PM Subject: Install on Windows 7: minimize the installation wizard, then only see a slice of the install page when finished Here is the problem(our QA found it): In Windows 7, install the build. When the installation starts, minimize the installation wizard. When the installation finished, the install wizard shows on the top-left of the screen. We can only see a slice of the install wizard(the close button X shows on the top-left). I have to hit the button Alt to call the system menu and hit Move to move the screen to the center of the screen to see the whole install page. Why is that? I also tried the Wix installer itself in Windows 7. It's the same thing. By the way, in XP, it works fine. I mean, I minimized it, after finished, the install page popup and shows in the center of the screen. I suspect this is the problem from MSI. But I'm not sure. Let me know if you know the reason and how to fix it. It might not be that a big deal, but I'd like to know. Thanks. Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Multiple languages issue: 'Error applying transforms' when select English in Danish 'Standards and format'
Our installer supports multiple languages. We are using the trick from here(http://jpassing.com/2007/06/14/authoring-multi-language-msi-packages/). Basically these are what we do: - We compile the wxs files - then link with different languages(we support en-US, es-ES, fr-FR, de-DE, pt-BR and it-IT) - then we get the transforms for each language - then we stuff the transforms in the MSI and we associate the language with the language ID - we also have a bootstrapper which provides a way the end user can choose the installing language, then internally, the bootstrapper will trigger the MSI by using the right transform - We even tested this case which works: in fr-FR(French) language environment, select the it-IT(Italian) language. Don't ask me why we tested this case, we just want to verify it works. This worked quite well until recently. One of our Denmark users reported this problem: - She's using English version of XP. She goes to [Control Panel]-[Regional and Language Options] and change the 'Standards and formats' to be 'Danish'. - Then she installed the build by selecting the English language. - She got Error applying transforms. Verify that the specified transform paths are valid. error. Actually, it doesn't have to be English, by choosing any other languages, the installation will be failed for this same error. Yes, we have 'Codepage=1252' in the wxl files. I then made some tests: 1. If I just build the English version, it works. There is no error. 2. If I just build any of other languages, it works as well. Say, the fr-FR one works in Danish environment. 3. But if I build the multiple language MSI, it fails. I mean, if I just run it msiexec.exe /i myinstaller.msi, then I got the Error applying transforms error. If I run it msiexec.exe /i myinstaller.msi TRANSFORMS=:1046.mst, I got the same error as well. 4. I also randomly tested it in some other Standards and formats. Some worked, some not. For example, it failed in Bulgarian environment as well. Here I have a few questions: 1. What is the problem here? And how to fix it? 2. If the it-IT transform works in fr-FR environment, how come es-ES(Spanish) doesn't work in Danish environment? I know we don't have Danish in our supported language list. But at least the English one should work in Danish format, correct? But it doesn't. Do you know why? 3. I understand by not giving the transform(msiexec.exe /i myinstaller.msi) the system will try to automatically 'match' the current language. I also know a way to force it to use certain language(msiexec.exe /i myinstaller.exe TRANSFORMS=:1046.mst). Is there a way to force to use English? I tried msiexec.exe /i myinstaller.exe TRANSFORMS=:1033.mst - but it doesn't work. This issue is quite important for us. Thanks in advance, /Brian __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Install on Windows 7: minimize the installation wizard, then only see a slice of the install page when finished
Here is the problem(our QA found it): In Windows 7, install the build. When the installation starts, minimize the installation wizard. When the installation finished, the install wizard shows on the top-left of the screen. We can only see a slice of the install wizard(the close button X shows on the top-left). I have to hit the button Alt to call the system menu and hit Move to move the screen to the center of the screen to see the whole install page. Why is that? I also tried the Wix installer itself in Windows 7. It's the same thing. By the way, in XP, it works fine. I mean, I minimized it, after finished, the install page popup and shows in the center of the screen. I suspect this is the problem from MSI. But I'm not sure. Let me know if you know the reason and how to fix it. It might not be that a big deal, but I'd like to know. Thanks. __ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The cancel installation string
By the way, I could change it to be Are you sure you want to cancel? to ignore the installation/remove operation. But if you have a better idea, please let me know. Thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Tue, January 12, 2010 2:04:07 PM Subject: The cancel installation string Our QA complains this: Reinstall the same build, then choose the Remove. During Remove, hit the Cancel button. The dialog box shows Are you sure you want to cancel ProductX installation? which our QA think it should be some like Are you sure you want to cancel ProductX removing?. Is there a way to satisfy our QA? I searched the language file and found: String Id=CancelDlgTextAre you sure you want to cancel [ProductName] installation?/String I doubt if we could change it as I thought the string CancelDlgText is used everywhere? Any ideas? Many thanks! /Brian Looking for the perfect gift?Give the gift of Flickr! __ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin
Thanks Phil for your info and the posts. If your customers include enterprises.. - Yes, we do have enterprise customers who do the installation for thousands of workstations. As you know, normally network admin will do this work. And the application won't be launched at the end because the installation normally was done silently. This is not the problem. The problem is our QA insist on this use case: the end user run as admin and further the application is launched as admin as well, then the settings will be saved in admin folder. Then next time, when the user run the application as a standard user, she will find her settings are gone. Actually not gone, but in admin folder. Even though I don't believe this is a valid use case, but I do own our QA a clear explanation about whether this can be done. So let's back to the original question, is possible to run as admin but launch application as standard user? If yes, then I suppose we'll need to use MSIREALADMINDETECTION as what Sascha pointed out. Then my further question is how to do that. Thanks again. From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, December 16, 2009 5:14:11 PM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin GPO is Group Policy Object. I think that's the right acronym, but anyway larger enterprises don't (for example) install Office on every system by going to each one and installing it. They assign it via group policy and have it install in admin mode even if users are not administrators. This kind of thing: http://technet.microsoft.com/en-us/library/cc179214.aspx and this where they talk about config files and the ability to specify license using PIDKEY. http://technet.microsoft.com/en-us/library/cc179195.aspx If your customers include enterprises that do that kind of deployment your product will be seen as much better than one that requires visiting each workstation for installation or license key configuration. Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Wednesday, December 16, 2009 3:57 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin Thanks Phil. For #1, in the old version of our software, the license key was kept in a common place. In this new version, it's changed. I agree with you for this point. I'll talk to our team to put license key in a common place. It'll make sense to put it in a common place as we support per-machine install. For #2, we could do that. But our QA also argued that all settings were saved in admin folder instead of user's local folder. Anyways, I think what our QA wanted is, run as admin but launch application as standard user. I'm not sure if this is possible. Can you tell me if it's possible? Also, what does GPO mean? Thanks! From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, December 16, 2009 3:29:57 PM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin ..and a couple of things that don't make sense to me: 1. There are always likely to be cases (admin install, over the shoulder, group policy) where somebody else is doing the install on behalf of a user. So what seems odd to me is Brian's comment that the key is in the wrong place because it's in the installing user's profile folder. Why not just install it in some common area in the first place? It's not as if you can't sub-directory the keys for each user in that location if necessary. 2. This sounds like standard data collection, so why not just have the user enter the key in a user sequence dialog, and have MSI put it somewhere on the system for you? Then you're not running programs with the wrong account. Also, if it's an installer property then it also enables silent installs, GPO installs. Have you looked at the PIDKEY property, for example? Phil Wilson -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Wednesday, December 16, 2009 1:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin Check out http://blogs.msdn.com/rflaming/archive/2006/09/21/765665.aspx You can probably use MSIREALADMINDETECTION to make the AdminUser property behave as you require. Sascha On Thu, Dec 17, 2009 at 6:08 AM, little.forest little.for...@ymail.com wrote: Our installer needs Admin right to run. So a Standard user has to run the installer run as Admin. On the final page of the installer, we have a Launch application
Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin
Thanks Sascha. Yes, we have some enterprise customers. As what I just replied to Phil's email, that's no problem for us. The problem is our QA insist on this use case: the end user run as admin and further the application is launched as admin as well, then the settings will be saved in admin folder. Then next time, when the user run the application as a standard user, she will find her settings are gone. Actually not gone, but in admin folder. Even though I don't believe this is a valid use case, but I do own our QA a clear explanation about whether this can be done. So let's back to the original question, is possible to run as admin but launch application as standard user? Do you know how to use MSIREALADMINDETECTION to detect if the invoker is admin or not? Some example will be appreciated. Thanks. From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, December 16, 2009 9:06:00 PM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin I agree with Phil here, If your customer base is in the corporate world, having an Enterprise ready installation is a must. One that can run with no user interaction, be configured pre-install and pushed out via GPO/AD (Group Policy Objects/Active Directory) so that the end user (non-Admin) can run the software without additional configuration, license keys, etc. i.e. If you have 5,000 workstations, you're not going to manually have an Administrator enter the license key on each one are you :) Sascha On Thu, Dec 17, 2009 at 12:14 PM, Wilson, Phil phil.wil...@wonderware.com wrote: GPO is Group Policy Object. I think that's the right acronym, but anyway larger enterprises don't (for example) install Office on every system by going to each one and installing it. They assign it via group policy and have it install in admin mode even if users are not administrators. This kind of thing: http://technet.microsoft.com/en-us/library/cc179214.aspx and this where they talk about config files and the ability to specify license using PIDKEY. http://technet.microsoft.com/en-us/library/cc179195.aspx If your customers include enterprises that do that kind of deployment your product will be seen as much better than one that requires visiting each workstation for installation or license key configuration. Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Wednesday, December 16, 2009 3:57 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin Thanks Phil. For #1, in the old version of our software, the license key was kept in a common place. In this new version, it's changed. I agree with you for this point. I'll talk to our team to put license key in a common place. It'll make sense to put it in a common place as we support per-machine install. For #2, we could do that. But our QA also argued that all settings were saved in admin folder instead of user's local folder. Anyways, I think what our QA wanted is, run as admin but launch application as standard user. I'm not sure if this is possible. Can you tell me if it's possible? Also, what does GPO mean? Thanks! From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, December 16, 2009 3:29:57 PM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin ..and a couple of things that don't make sense to me: 1. There are always likely to be cases (admin install, over the shoulder, group policy) where somebody else is doing the install on behalf of a user. So what seems odd to me is Brian's comment that the key is in the wrong place because it's in the installing user's profile folder. Why not just install it in some common area in the first place? It's not as if you can't sub-directory the keys for each user in that location if necessary. 2. This sounds like standard data collection, so why not just have the user enter the key in a user sequence dialog, and have MSI put it somewhere on the system for you? Then you're not running programs with the wrong account. Also, if it's an installer property then it also enables silent installs, GPO installs. Have you looked at the PIDKEY property, for example? Phil Wilson -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Wednesday, December 16, 2009 1:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin Check out http://blogs.msdn.com
Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin
Thank you very much for your reply, Phil. Well, I totally agree your thoughts about QA etc. I ever worked at one of the biggest companies in the software field. I know the software process, V-cycle, spec, unit test, integration test, system test etc. But in my current company, believe it or not, we don't have spec or software requirement or that kind of thing on paper. All requirement is in our PM's(Project Manager) head. Actually, I've a feeling that our dev manager is glad to see developers struggle with QA to improve product quality. Also there are some other weird things out there in the company, for example, they encourage people to change other people's code without telling any one. The guy proposed this idea is now working at another big company as a key person. The guy who actually did the most changes(mess up) to other's code was new prompted. What can you do about it? Don't get me wrong. I am positive. I was actually publicly against these wrong ideas - no luck. Actually, I believe there are quite a few this sort of companies out there. Sorry for the TMI(Too Much Information). Back to business. So basically the run-as-admin but launch app as-standard-user isn't possible. Am I right? Thanks. From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Thu, December 17, 2009 9:37:47 AM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin My experience has always been that QA verifies that the product works as designed and meets the spec. But your company allows QA to make significant decisions on where files are saved, in this case apparently with the consequence that licensing doesn't work for all users? Interesting Whether you can run a custom action as limited user depends on several variables, one of them being the OS. On UAC systems immediate custom actions are not elevated, so that's a possibility, but if you launch your MSI with an elevated bootstrapper I believe everything is elevated. Pre-UAC I can't think of any way to do what you're doing other than something like having the program delete the rights it's not supposed to be using, i.e. give itself limited user rights. Must this program run from the install? Why not have the app come up and notice that this user hasn't yet been authorized and do the license key thing then? Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, December 17, 2009 12:19 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin Thanks Phil for your info and the posts. If your customers include enterprises.. - Yes, we do have enterprise customers who do the installation for thousands of workstations. As you know, normally network admin will do this work. And the application won't be launched at the end because the installation normally was done silently. This is not the problem. The problem is our QA insist on this use case: the end user run as admin and further the application is launched as admin as well, then the settings will be saved in admin folder. Then next time, when the user run the application as a standard user, she will find her settings are gone. Actually not gone, but in admin folder. Even though I don't believe this is a valid use case, but I do own our QA a clear explanation about whether this can be done. So let's back to the original question, is possible to run as admin but launch application as standard user? If yes, then I suppose we'll need to use MSIREALADMINDETECTION as what Sascha pointed out. Then my further question is how to do that. Thanks again. From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, December 16, 2009 5:14:11 PM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin GPO is Group Policy Object. I think that's the right acronym, but anyway larger enterprises don't (for example) install Office on every system by going to each one and installing it. They assign it via group policy and have it install in admin mode even if users are not administrators. This kind of thing: http://technet.microsoft.com/en-us/library/cc179214.aspx and this where they talk about config files and the ability to specify license using PIDKEY. http://technet.microsoft.com/en-us/library/cc179195.aspx If your customers include enterprises that do that kind of deployment your product will be seen as much better than one that requires visiting each workstation for installation or license key configuration. Phil Wilson -Original Message- From: little.forest
Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin
I really appreciate it, Phil. I'll look into CreateRestrictedToken and CreateProcessAsUser. From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Thu, December 17, 2009 11:50:40 AM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin I don't believe there is one solution that fits every OS and all the variations of UAC vs non-UAC, launching with an elevated bootstrapper or launching from an administrative prompt that can be used in the install. There are probably solutions where the program itself can do what you want. For example, I think it is possible for the program (before it shows UI) to detect its excessive privilege, create a restricted token (CreateRestrictedToken), and then use CreateProcessAsUser to launch itself again using that restricted token, assuming that all you want to do is run as the installing user except with limited rights. CreateRestrictedToken has documentation that explains this. Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, December 17, 2009 10:30 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin Thank you very much for your reply, Phil. Well, I totally agree your thoughts about QA etc. I ever worked at one of the biggest companies in the software field. I know the software process, V-cycle, spec, unit test, integration test, system test etc. But in my current company, believe it or not, we don't have spec or software requirement or that kind of thing on paper. All requirement is in our PM's(Project Manager) head. Actually, I've a feeling that our dev manager is glad to see developers struggle with QA to improve product quality. Also there are some other weird things out there in the company, for example, they encourage people to change other people's code without telling any one. The guy proposed this idea is now working at another big company as a key person. The guy who actually did the most changes(mess up) to other's code was new prompted. What can you do about it? Don't get me wrong. I am positive. I was actually publicly against these wrong ideas - no luck. Actually, I believe there are quite a few this sort of companies out there. Sorry for the TMI(Too Much Information). Back to business. So basically the run-as-admin but launch app as-standard-user isn't possible. Am I right? Thanks. From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Thu, December 17, 2009 9:37:47 AM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin My experience has always been that QA verifies that the product works as designed and meets the spec. But your company allows QA to make significant decisions on where files are saved, in this case apparently with the consequence that licensing doesn't work for all users? Interesting Whether you can run a custom action as limited user depends on several variables, one of them being the OS. On UAC systems immediate custom actions are not elevated, so that's a possibility, but if you launch your MSI with an elevated bootstrapper I believe everything is elevated. Pre-UAC I can't think of any way to do what you're doing other than something like having the program delete the rights it's not supposed to be using, i.e. give itself limited user rights. Must this program run from the install? Why not have the app come up and notice that this user hasn't yet been authorized and do the license key thing then? Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, December 17, 2009 12:19 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin Thanks Phil for your info and the posts. If your customers include enterprises.. - Yes, we do have enterprise customers who do the installation for thousands of workstations. As you know, normally network admin will do this work. And the application won't be launched at the end because the installation normally was done silently. This is not the problem. The problem is our QA insist on this use case: the end user run as admin and further the application is launched as admin as well, then the settings will be saved in admin folder. Then next time, when the user run the application as a standard user, she will find her settings are gone. Actually not gone, but in admin folder. Even though I don't believe this is a valid use case, but I do own our QA a clear explanation about whether this can
[WiX-users] How to launch application as Standard User while the installer ran as Admin
Our installer needs Admin right to run. So a Standard user has to run the installer run as Admin. On the final page of the installer, we have a Launch application option. So the user can check that option and launch the application. Our application will ask a license key. The user inputs the license key. But the key will be saved in C:\Documents and Settings\Administrator\Application Data folder. Then the user exits the application. And run the application again by using the normal Standard user privilege. Then the application will ask the license key again, because the license key wasn't saved in the right folder such as C:\Documents and Settings\JoeSmith\Application Data. How to resolve this problem? I'm thinking two options: 1. The user can run as admin. But the application will be launched by using Standard user. This way, the license key input by the user will be saved in the correct spot, namely, the users setting folder like C:\Documents and Settings\JoeSmith\Application Data. But how to do it? 2. If there is a way that the installer can detect this installation was from run as admin, then set a property. Then in the final page's launch application option, we'll check this property. If it's set then we disable the launch application option. This will stop the user running the application as admin - they don't need to input license key two times. Is there a way to detect if the installation run as admin? By the way, we're using the code example from Wix.chm How To: Run the Installed Application After Setup section. Thanks in advance. /Brian __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin
Thanks Sascha. I'll look into it. From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, December 16, 2009 1:33:35 PM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin Check out http://blogs.msdn.com/rflaming/archive/2006/09/21/765665.aspx You can probably use MSIREALADMINDETECTION to make the AdminUser property behave as you require. Sascha On Thu, Dec 17, 2009 at 6:08 AM, little.forest little.for...@ymail.com wrote: Our installer needs Admin right to run. So a Standard user has to run the installer run as Admin. On the final page of the installer, we have a Launch application option. So the user can check that option and launch the application. Our application will ask a license key. The user inputs the license key. But the key will be saved in C:\Documents and Settings\Administrator\Application Data folder. Then the user exits the application. And run the application again by using the normal Standard user privilege. Then the application will ask the license key again, because the license key wasn't saved in the right folder such as C:\Documents and Settings\JoeSmith\Application Data. How to resolve this problem? I'm thinking two options: 1. The user can run as admin. But the application will be launched by using Standard user. This way, the license key input by the user will be saved in the correct spot, namely, the users setting folder like C:\Documents and Settings\JoeSmith\Application Data. But how to do it? 2. If there is a way that the installer can detect this installation was from run as admin, then set a property. Then in the final page's launch application option, we'll check this property. If it's set then we disable the launch application option. This will stop the user running the application as admin - they don't need to input license key two times. Is there a way to detect if the installation run as admin? By the way, we're using the code example from Wix.chm How To: Run the Installed Application After Setup section. Thanks in advance. /Brian __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ 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 Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin
Thanks Phil. For #1, in the old version of our software, the license key was kept in a common place. In this new version, it's changed. I agree with you for this point. I'll talk to our team to put license key in a common place. It'll make sense to put it in a common place as we support per-machine install. For #2, we could do that. But our QA also argued that all settings were saved in admin folder instead of user's local folder. Anyways, I think what our QA wanted is, run as admin but launch application as standard user. I'm not sure if this is possible. Can you tell me if it's possible? Also, what does GPO mean? Thanks! From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, December 16, 2009 3:29:57 PM Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin ..and a couple of things that don't make sense to me: 1. There are always likely to be cases (admin install, over the shoulder, group policy) where somebody else is doing the install on behalf of a user. So what seems odd to me is Brian's comment that the key is in the wrong place because it's in the installing user's profile folder. Why not just install it in some common area in the first place? It's not as if you can't sub-directory the keys for each user in that location if necessary. 2. This sounds like standard data collection, so why not just have the user enter the key in a user sequence dialog, and have MSI put it somewhere on the system for you? Then you're not running programs with the wrong account. Also, if it's an installer property then it also enables silent installs, GPO installs. Have you looked at the PIDKEY property, for example? Phil Wilson -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Wednesday, December 16, 2009 1:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to launch application as Standard User while the installer ran as Admin Check out http://blogs.msdn.com/rflaming/archive/2006/09/21/765665.aspx You can probably use MSIREALADMINDETECTION to make the AdminUser property behave as you require. Sascha On Thu, Dec 17, 2009 at 6:08 AM, little.forest little.for...@ymail.com wrote: Our installer needs Admin right to run. So a Standard user has to run the installer run as Admin. On the final page of the installer, we have a Launch application option. So the user can check that option and launch the application. Our application will ask a license key. The user inputs the license key. But the key will be saved in C:\Documents and Settings\Administrator\Application Data folder. Then the user exits the application. And run the application again by using the normal Standard user privilege. Then the application will ask the license key again, because the license key wasn't saved in the right folder such as C:\Documents and Settings\JoeSmith\Application Data. How to resolve this problem? I'm thinking two options: 1. The user can run as admin. But the application will be launched by using Standard user. This way, the license key input by the user will be saved in the correct spot, namely, the users setting folder like C:\Documents and Settings\JoeSmith\Application Data. But how to do it? 2. If there is a way that the installer can detect this installation was from run as admin, then set a property. Then in the final page's launch application option, we'll check this property. If it's set then we disable the launch application option. This will stop the user running the application as admin - they don't need to input license key two times. Is there a way to detect if the installation run as admin? By the way, we're using the code example from Wix.chm How To: Run the Installed Application After Setup section. Thanks in advance. /Brian __ Make your browsing faster, safer, and easier with the new Internet Explorer(r) 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ 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 Verizon Developer Community Take advantage
Re: [WiX-users] How to force to launch application in silent install mode?
Thanks Sascha. Rebooting doesn't fit our requirement. I've made a workaround in our bootstrapper to launch the app after silent installation. It's not nice as our MSI users won't have this functionality. But this seems the best we could do so far. From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wednesday, November 18, 2009 4:10:56 PM Subject: Re: [WiX-users] How to force to launch application in silent install mode? Best solution I've used in the past was to schedule a reboot, it really depends on your app and your deployment requirements as to what will work for you. On Thu, Nov 19, 2009 at 10:13 AM, little.forest little.for...@ymail.com wrote: Thanks Sascha. I see your points. It looks like there is no any other workarounds, correct? From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wednesday, November 18, 2009 2:35:26 PM Subject: Re: [WiX-users] How to force to launch application in silent install mode? Hi, With regards to the quicklaunch shortcut, the checkbox is just setting a property, no different to setting the property on the command line. The property is set when InstallExecuteSequence runs, and you most likely have a condition on your quicklaunch component that checks the property. With regards to launching the application, you're tying the launch to the Finish button in the InstallUiSequence rather than to something that happens during InstallExecuteSequence. The following page might help explain the sequence: http://blogs.msdn.com/rflaming/archive/2006/09/21/765452.aspx Sascha On Thu, Nov 19, 2009 at 6:00 AM, little.forest little.for...@ymail.com wrote: Thanks Sascha. It's good to know that the InstallUISequence is never executed in quite mode. But in another case, I set a property in command line argument, it seems working. I mean, we have a checkbox called Install Quick Launch shortcut. By default it's off. So the quick launch shortcut isn't created by default. In command line, I added this 'INSTALLQUICKLAUNCHSHORTCUT=1' in command line, then in quite installation, the quick launch shortcut was created. So it seems working. I wonder why the similar case for Launch application on the final page would be different? I thought it's supposed to work the same way as the quick launch shortcut, right? Let me know if you know the reason. By the way, the reason we need to launch the application in quite installation is because these: we have an auto-update mechanism. The idea is, the application will periodically check if there is any new build available in our provisioning server. If there is any new version, then ask the end user if she wants to download it and install it. If the end user says yes, then we'll download it and install it. After installation of the new version, we'd like to automatically launch the application, because the previous status of the application was in running state. This is just like when you update your browser like Firefox or Chrome. I think it's okay if the application isn't launched by default in quite mode. But by setting some kind of property, the application will be launched in quite mode. This will satisfy both the network admin scenario as what you mentioned, and our case. Anyways, since it's not supported, I'll think about if I can schedule this launching action in our bootstrapper - we have a bootstrapper for the installer. Thanks again. From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, November 17, 2009 8:06:13 PM Subject: Re: [WiX-users] How to force to launch application in silent install mode? In quite mode, the InstallUISequence is never executed, so the checkbox doesn't even really exist (only the property related to the checkbox) The documentation shows how to tie in execution to when the user clicks the Finish button - this button never exists and is never pushed in a silent installation so the application will never launch. Launching an application automatically during a quiet installation sounds like a *really bad idea* - what if someone pushes out the installation via Group Policy? How does your application handle being executed under a system administrator account with no desktop to interact with? Your best bet is to schedule the application to launch at next login using the RunOnce registry key, and then forcing a reboot post-install. That way you can be certain the application will launch in a user context, rather than in an elevated context - even though the reboot may be an inconvenience at least you'll end up with a more
Re: [WiX-users] How to force to launch application in silent install mode?
Thanks Sascha. It's good to know that the InstallUISequence is never executed in quite mode. But in another case, I set a property in command line argument, it seems working. I mean, we have a checkbox called Install Quick Launch shortcut. By default it's off. So the quick launch shortcut isn't created by default. In command line, I added this 'INSTALLQUICKLAUNCHSHORTCUT=1' in command line, then in quite installation, the quick launch shortcut was created. So it seems working. I wonder why the similar case for Launch application on the final page would be different? I thought it's supposed to work the same way as the quick launch shortcut, right? Let me know if you know the reason. By the way, the reason we need to launch the application in quite installation is because these: we have an auto-update mechanism. The idea is, the application will periodically check if there is any new build available in our provisioning server. If there is any new version, then ask the end user if she wants to download it and install it. If the end user says yes, then we'll download it and install it. After installation of the new version, we'd like to automatically launch the application, because the previous status of the application was in running state. This is just like when you update your browser like Firefox or Chrome. I think it's okay if the application isn't launched by default in quite mode. But by setting some kind of property, the application will be launched in quite mode. This will satisfy both the network admin scenario as what you mentioned, and our case. Anyways, since it's not supported, I'll think about if I can schedule this launching action in our bootstrapper - we have a bootstrapper for the installer. Thanks again. From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, November 17, 2009 8:06:13 PM Subject: Re: [WiX-users] How to force to launch application in silent install mode? In quite mode, the InstallUISequence is never executed, so the checkbox doesn't even really exist (only the property related to the checkbox) The documentation shows how to tie in execution to when the user clicks the Finish button - this button never exists and is never pushed in a silent installation so the application will never launch. Launching an application automatically during a quiet installation sounds like a *really bad idea* - what if someone pushes out the installation via Group Policy? How does your application handle being executed under a system administrator account with no desktop to interact with? Your best bet is to schedule the application to launch at next login using the RunOnce registry key, and then forcing a reboot post-install. That way you can be certain the application will launch in a user context, rather than in an elevated context - even though the reboot may be an inconvenience at least you'll end up with a more reliable setup thats isn't dependent on how the user chooses to install (command line, elevated, non-elevated, group policy, quiet, interactive, etc). Sascha On Wed, Nov 18, 2009 at 12:50 PM, little.forest little.for...@ymail.com wrote: In our code, we have this: Property Id=WIXUI_EXITDIALOGOPTIONALCHECKBOX Value=1 / So the checkbox is checked by default. I thought that means launch the application by default. But the application was not launched in quite(silent) mode: msiexec /i myapp.msi /qr I then tried to set property in command line, it didn't work either: msiexec /i myapp.msi WIXUI_EXITDIALOGOPTIONALCHECKBOX=1 /qr Do you know how to automatically launch the application in quiet(silent) mode? Thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Tuesday, November 17, 2009 2:20:58 PM Subject: [WiX-users] How to force to launch application in silent install mode? I'd like to know how to force to launch the application in silent install mode. I thought this would work: msiexec /i myapp.msi WIXUI_EXITDIALOGOPTIONALCHECKBOX=1 /qr But after installation, the application wasn't launched. By the way, we use the 'standard' way from Wix.chm(How To: Run the Installed Application After Setup) for the 'launch application'. How can I make the application run anyways after a silent installation? By the way, from the log, the CustomAction LaunchApplication never run. I don't know why it didn't run. Thanks. /Brian __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Let Crystal Reports handle the reporting - Free Crystal Reports
Re: [WiX-users] How to force to launch application in silent install mode?
If you happens to know how to launch the application in quite(silent) mode, please let me know. Thanks. From: little.forest little.for...@ymail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wednesday, November 18, 2009 11:00:16 AM Subject: Re: [WiX-users] How to force to launch application in silent install mode? Thanks Sascha. It's good to know that the InstallUISequence is never executed in quite mode. But in another case, I set a property in command line argument, it seems working. I mean, we have a checkbox called Install Quick Launch shortcut. By default it's off. So the quick launch shortcut isn't created by default. In command line, I added this 'INSTALLQUICKLAUNCHSHORTCUT=1' in command line, then in quite installation, the quick launch shortcut was created. So it seems working. I wonder why the similar case for Launch application on the final page would be different? I thought it's supposed to work the same way as the quick launch shortcut, right? Let me know if you know the reason. By the way, the reason we need to launch the application in quite installation is because these: we have an auto-update mechanism. The idea is, the application will periodically check if there is any new build available in our provisioning server. If there is any new version, then ask the end user if she wants to download it and install it. If the end user says yes, then we'll download it and install it. After installation of the new version, we'd like to automatically launch the application, because the previous status of the application was in running state. This is just like when you update your browser like Firefox or Chrome. I think it's okay if the application isn't launched by default in quite mode. But by setting some kind of property, the application will be launched in quite mode. This will satisfy both the network admin scenario as what you mentioned, and our case. Anyways, since it's not supported, I'll think about if I can schedule this launching action in our bootstrapper - we have a bootstrapper for the installer. Thanks again. From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, November 17, 2009 8:06:13 PM Subject: Re: [WiX-users] How to force to launch application in silent install mode? In quite mode, the InstallUISequence is never executed, so the checkbox doesn't even really exist (only the property related to the checkbox) The documentation shows how to tie in execution to when the user clicks the Finish button - this button never exists and is never pushed in a silent installation so the application will never launch. Launching an application automatically during a quiet installation sounds like a *really bad idea* - what if someone pushes out the installation via Group Policy? How does your application handle being executed under a system administrator account with no desktop to interact with? Your best bet is to schedule the application to launch at next login using the RunOnce registry key, and then forcing a reboot post-install. That way you can be certain the application will launch in a user context, rather than in an elevated context - even though the reboot may be an inconvenience at least you'll end up with a more reliable setup thats isn't dependent on how the user chooses to install (command line, elevated, non-elevated, group policy, quiet, interactive, etc). Sascha On Wed, Nov 18, 2009 at 12:50 PM, little.forest little.for...@ymail.com wrote: In our code, we have this: Property Id=WIXUI_EXITDIALOGOPTIONALCHECKBOX Value=1 / So the checkbox is checked by default. I thought that means launch the application by default. But the application was not launched in quite(silent) mode: msiexec /i myapp.msi /qr I then tried to set property in command line, it didn't work either: msiexec /i myapp.msi WIXUI_EXITDIALOGOPTIONALCHECKBOX=1 /qr Do you know how to automatically launch the application in quiet(silent) mode? Thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Tuesday, November 17, 2009 2:20:58 PM Subject: [WiX-users] How to force to launch application in silent install mode? I'd like to know how to force to launch the application in silent install mode. I thought this would work: msiexec /i myapp.msi WIXUI_EXITDIALOGOPTIONALCHECKBOX=1 /qr But after installation, the application wasn't launched. By the way, we use the 'standard' way from Wix.chm(How To: Run the Installed Application After Setup) for the 'launch application'. How can I make the application run anyways after a silent installation? By the way, from the log, the CustomAction LaunchApplication never run. I don't know why it didn't run
Re: [WiX-users] How to force to launch application in silent install mode?
Thanks Sascha. I see your points. It looks like there is no any other workarounds, correct? From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wednesday, November 18, 2009 2:35:26 PM Subject: Re: [WiX-users] How to force to launch application in silent install mode? Hi, With regards to the quicklaunch shortcut, the checkbox is just setting a property, no different to setting the property on the command line. The property is set when InstallExecuteSequence runs, and you most likely have a condition on your quicklaunch component that checks the property. With regards to launching the application, you're tying the launch to the Finish button in the InstallUiSequence rather than to something that happens during InstallExecuteSequence. The following page might help explain the sequence: http://blogs.msdn.com/rflaming/archive/2006/09/21/765452.aspx Sascha On Thu, Nov 19, 2009 at 6:00 AM, little.forest little.for...@ymail.com wrote: Thanks Sascha. It's good to know that the InstallUISequence is never executed in quite mode. But in another case, I set a property in command line argument, it seems working. I mean, we have a checkbox called Install Quick Launch shortcut. By default it's off. So the quick launch shortcut isn't created by default. In command line, I added this 'INSTALLQUICKLAUNCHSHORTCUT=1' in command line, then in quite installation, the quick launch shortcut was created. So it seems working. I wonder why the similar case for Launch application on the final page would be different? I thought it's supposed to work the same way as the quick launch shortcut, right? Let me know if you know the reason. By the way, the reason we need to launch the application in quite installation is because these: we have an auto-update mechanism. The idea is, the application will periodically check if there is any new build available in our provisioning server. If there is any new version, then ask the end user if she wants to download it and install it. If the end user says yes, then we'll download it and install it. After installation of the new version, we'd like to automatically launch the application, because the previous status of the application was in running state. This is just like when you update your browser like Firefox or Chrome. I think it's okay if the application isn't launched by default in quite mode. But by setting some kind of property, the application will be launched in quite mode. This will satisfy both the network admin scenario as what you mentioned, and our case. Anyways, since it's not supported, I'll think about if I can schedule this launching action in our bootstrapper - we have a bootstrapper for the installer. Thanks again. From: Sascha Beaumont sascha.beaum...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, November 17, 2009 8:06:13 PM Subject: Re: [WiX-users] How to force to launch application in silent install mode? In quite mode, the InstallUISequence is never executed, so the checkbox doesn't even really exist (only the property related to the checkbox) The documentation shows how to tie in execution to when the user clicks the Finish button - this button never exists and is never pushed in a silent installation so the application will never launch. Launching an application automatically during a quiet installation sounds like a *really bad idea* - what if someone pushes out the installation via Group Policy? How does your application handle being executed under a system administrator account with no desktop to interact with? Your best bet is to schedule the application to launch at next login using the RunOnce registry key, and then forcing a reboot post-install. That way you can be certain the application will launch in a user context, rather than in an elevated context - even though the reboot may be an inconvenience at least you'll end up with a more reliable setup thats isn't dependent on how the user chooses to install (command line, elevated, non-elevated, group policy, quiet, interactive, etc). Sascha On Wed, Nov 18, 2009 at 12:50 PM, little.forest little.for...@ymail.com wrote: In our code, we have this: Property Id=WIXUI_EXITDIALOGOPTIONALCHECKBOX Value=1 / So the checkbox is checked by default. I thought that means launch the application by default. But the application was not launched in quite(silent) mode: msiexec /i myapp.msi /qr I then tried to set property in command line, it didn't work either: msiexec /i myapp.msi WIXUI_EXITDIALOGOPTIONALCHECKBOX=1 /qr Do you know how to automatically launch the application in quiet(silent) mode? Thanks. From: little.forest little.for
[WiX-users] How to force to launch application in silent install mode?
I'd like to know how to force to launch the application in silent install mode. I thought this would work: msiexec /i myapp.msi WIXUI_EXITDIALOGOPTIONALCHECKBOX=1 /qr But after installation, the application wasn't launched. By the way, we use the 'standard' way from Wix.chm(How To: Run the Installed Application After Setup) for the 'launch application'. How can I make the application run anyways after a silent installation? By the way, from the log, the CustomAction LaunchApplication never run. I don't know why it didn't run. Thanks. /Brian __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to force to launch application in silent install mode?
In our code, we have this: Property Id=WIXUI_EXITDIALOGOPTIONALCHECKBOX Value=1 / So the checkbox is checked by default. I thought that means launch the application by default. But the application was not launched in quite(silent) mode: msiexec /i myapp.msi /qr I then tried to set property in command line, it didn't work either: msiexec /i myapp.msi WIXUI_EXITDIALOGOPTIONALCHECKBOX=1 /qr Do you know how to automatically launch the application in quiet(silent) mode? Thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Tuesday, November 17, 2009 2:20:58 PM Subject: [WiX-users] How to force to launch application in silent install mode? I'd like to know how to force to launch the application in silent install mode. I thought this would work: msiexec /i myapp.msi WIXUI_EXITDIALOGOPTIONALCHECKBOX=1 /qr But after installation, the application wasn't launched. By the way, we use the 'standard' way from Wix.chm(How To: Run the Installed Application After Setup) for the 'launch application'. How can I make the application run anyways after a silent installation? By the way, from the log, the CustomAction LaunchApplication never run. I don't know why it didn't run. Thanks. /Brian __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Some text on progress dialog
Thanks Blair. After removed those curly braces, it works. I'll log a bug. Thanks again. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Friday, November 6, 2009 6:56:44 PM Subject: Re: [WiX-users] Some text on progress dialog It doesn't like the '}' chars, especially when they replace missing ']' chars. Looks like a bug. Please file it. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Friday, November 06, 2009 2:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some text on progress dialog Thanks Blair. There is a new problem after I added the WixUI_ErrorProgressText line yesterday. I tested the build itself yesterday. It worked. But when I took a closer look at the build log this morning, I found there are some link errors. The en-US, es-ES, it-IT and pt-BR languages are fine. But the de-DE and fr-FR languages have the error. For example, for de-DE: C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\ErrorProgressText.wx s(167) : error LGHT0204 : ICE03: Invalid template string; Table: Error, Column: Message, Key(s): 1603 C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\ErrorProgressText.wx s(230) : error LGHT0204 : ICE03: Invalid template string; Table: Error, Column: Message, Key(s): 1918 C:\delivery\Dev\wix30_public\src\ext\UIExtension\wixlib\ErrorProgressText.wx s(231) : error LGHT0204 : ICE03: Invalid template string; Table: Error, Column: Message, Key(s): 1919 I then opened the WixUI_de-de.wxl. I did see the string definitions for 1603, 1918 and 1919: String Id=Error1603Die Datei [2][3] wird im Augenblick von folgendem Prozess verwendet: Name: [4], ID: [5], Fenstertitel: [6]}. Schließen Sie diese Anwendung, und wiederholen Sie den Vorgang./String ... String Id=Error1918Fehler beim Installieren des ODBC-Treibers: [4]. ODBC-Fehler [2]: [3}. Stellen Sie sicher, dass die Datei [4] vorhanden ist und Sie darauf zugreifen können./String String Id=Error1919Fehler beim Konfigurieren der ODBC-Datenquelle: [4]. ODBC-Fehler [2]: [3}. Stellen Sie sicher, dass die Datei [4] vorhanden ist und Sie darauf zugreifen können./String Do you know why I'm getting these link errors? For fr-FR, it complains the string 1721 isn't defined. But of course, it's defined in the fr-FR wxl file. Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Thursday, November 5, 2009 6:12:52 PM Subject: Re: [WiX-users] Some text on progress dialog Yes. 1033 = en-US = English (United States). The attribute's value needs to be the decimal LCID value. A list of LCIDs are here: http://msdn.microsoft.com/en-us/goglobal/bb964664.aspx -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, November 05, 2009 5:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some text on progress dialog Thanks Blair. You're a truly expert on Wix. I added UIRef Id=WixUI_ErrorProgressText/ in my code. It works! By the way, how does LCID work? Currently, in my code, I have Language='1033' in my code, is this okay? Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, November 3, 2009 10:18:47 PM Subject: Re: [WiX-users] Some text on progress dialog If you want to use the WiX-supplied values, you need to have the following element in your authoring: UIRef Id=WixUI_ErrorProgressText/ and have es-es in your -Cultures parameter for light.exe. Otherwise, you need to make sure your ProductLanguage is set to some LCID that identifies Spanish so it will use the strings from the OS (assuming the OS has Spanish language support installed). -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Tuesday, November 03, 2009 5:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Some text on progress dialog We use Wix 3.0. In the progress dialog, there are some text showing during installation such as Starting services, Copying new files or Stopping services. I wonder if these text configurable based on different language? I found these string IDs and add the translation in each wxl files. But it doesn't seem working. It still always shows English no matter what language we choose. For instance, I have these in the WinUI_es-es.wxl: String Id=ProgressTextStartServicesIniciando servicios/String String Id=ProgressTextInstallFilesCopiando archivos nuevos/String String Id=ProgressTextStopServicesDeteniendo servicios/String String Id=ProgressTextCreateShortcutsCreando accesos directos/String String Id=ProgressTextRegisterProductRegistrando producto/String String Id=ProgressTextRollbackCleanupQuitando
Re: [WiX-users] How to show other language on GUI when installing .NET 3.5 framework
Maybe this is not a great place to ask, but if you know - I wonder if there is a way to install the .NET 3.5 framework by showing non-English language on GUI. Is it possible? I tried dotnetfx35setup.exe /lang:FRA, but it still shows English. Thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Friday, November 6, 2009 5:39:39 PM Subject: [WiX-users] How to show other language on GUI when installing .NET 3.5 framework I'm trying to figure out a way to show different language(not English) in GUI when installing .NET 3.5 framework. According to this post(http://blogs.msdn.com/astebner/archive/2008/01/21/7191582.aspx): dotnetfx35setup.exe /lang:FRA I tried it. It doesn't work. It still shows English. Maybe I shouldn't post this question in this forum. But if you know the answer, please let me know. Thanks. __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Some text on progress dialog
Thanks Blair. You're a truly expert on Wix. I added UIRef Id=WixUI_ErrorProgressText/ in my code. It works! By the way, how does LCID work? Currently, in my code, I have Language='1033' in my code, is this okay? Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, November 3, 2009 10:18:47 PM Subject: Re: [WiX-users] Some text on progress dialog If you want to use the WiX-supplied values, you need to have the following element in your authoring: UIRef Id=WixUI_ErrorProgressText/ and have es-es in your -Cultures parameter for light.exe. Otherwise, you need to make sure your ProductLanguage is set to some LCID that identifies Spanish so it will use the strings from the OS (assuming the OS has Spanish language support installed). -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Tuesday, November 03, 2009 5:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Some text on progress dialog We use Wix 3.0. In the progress dialog, there are some text showing during installation such as Starting services, Copying new files or Stopping services. I wonder if these text configurable based on different language? I found these string IDs and add the translation in each wxl files. But it doesn't seem working. It still always shows English no matter what language we choose. For instance, I have these in the WinUI_es-es.wxl: String Id=ProgressTextStartServicesIniciando servicios/String String Id=ProgressTextInstallFilesCopiando archivos nuevos/String String Id=ProgressTextStopServicesDeteniendo servicios/String String Id=ProgressTextCreateShortcutsCreando accesos directos/String String Id=ProgressTextRegisterProductRegistrando producto/String String Id=ProgressTextRollbackCleanupQuitando archivos de copia de seguridad/String But the Spanish installer still shows English. I doubt if these strings are from shell? Namely, they can't be customized based on the language? But I'm not sure. Let me know if you know it. Thanks. /Brian __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0: link error when using '*' in the component's GUID field
Thanks Blair.
I tried it by using your code example. It works!
But I found a problem, after uninstallation, this registry entry is still in
the registry. Even if I use createAndRemoveOnUninstall, it's still there. I
checked the uninstall log, it doesn't say if the delete key operation is okay
or not:
MSI (s) (D0:C0) [17:25:45:891]: Executing op: RegRemoveValue(Name=MyApp
3.0,Value=[INSTALLLOCATION]MyApp30.exe[RunWhenWindowsStartsArgument],)
MSI (s) (D0:C0) [17:25:45:891]: Note: 1: 1402 2:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run 3: 2
MSI (s) (D0:C0) [17:25:45:891]: Executing op: RegRemoveKey()
What can I do to make sure this registry entry is deleted upon uninstalling?
Also, you mentioned You may need to preserve RUNWHENWINDOWSSTART and restore
it during repairs
and/or small updates/minor upgrades so that the value doesn't change during
a repair. - we use major upgrade, does it matter for us? If so, what is the
use case or test scenario to verify our install is fine with this restraint?
Thanks.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Friday, October 30, 2009 5:54:06 PM
Subject: Re: [WiX-users] Wix 3.0: link error when using '*' in the component's
GUID field
Identity theft is always such a pain.
compone...@guid='*' is required to generate a stable guid. That means that
if the component's keypath didn't change, it is the same component. As a
result, both of your components, which share the exact same keypath, are the
same component as far as Windows Installer is concerned (they share the same
identity). The value isn't part of the keypath, unfortunately.
What you may consider doing instead is (since your components are currently
not transitive and are mutually exclusive) is something like this:
SetProperty Id='RunValueArgument' Value=' -bootload' Sequence='execute'
Before='WriteRegistryValues'![CDATA[RUNWHENWINDOWSSTART
1]]/SetProperty
Component Id=RunRegistry Guid=*
RegistryKey
Root=HKCU
Key=Software\Microsoft\Windows\CurrentVersion\Run
Action=create
RegistryValue
Type=string
Name=$(var.ProductName)
Value='[INSTALLLOCATION]$(var.FileOutput)[RunValueArgument]'
KeyPath=yes
/
/RegistryKey
/Component
You may need to preserve RUNWHENWINDOWSSTART and restore it during repairs
and/or small updates/minor upgrades so that the value doesn't change during
a repair.
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Friday, October 30, 2009 2:27 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix 3.0: link error when using '*' in the component's
GUID field
We use Wix 3.0.4805.0.
We run into a very strange link error: we have a component that uses * as
the GUID. But when we link it, it reports an error:
error LGHT0204 : ICE08: Component: RegistrySpecial has a duplicate GUID:
{A7C1768B-FF73-5DFC-8E76-E810E013F78A}
But I searched all of our source code, there is no GUID
{A7C1768B-FF73-5DFC-8E76-E810E013F78A} defined anywhere.
Here is the command line to compile and link it:
candle.exe -dRelease -out .wixobj file -arch x86 -ext ext dll files
myapp.wxs
light.exe -ext EXT_DLL_FILE -cultures:en-us -out myapp.msi -pdbout
PDB_FILE -loc LANG_FILE some .wixobj files
Basically, this is what we'd like to do:
there is an option called Start application when Windows starts. If the
end user select this option, we'll write the application's file path to a
registry entry; if the end user doesn't select this option, we'll also write
the entry with a parameter. The logic is just like this:
if (RUNWHENWINDOWSSTART) {
write registry with [PATH_TO_APP]
} else {
write registry with [PATH_TO_APP] -bootload
}
Here is the code:
Component Id=RegistryNormal Guid=*
ConditionRUNWHENWINDOWSSTART = 1/Condition
RegistryKey
Root=HKCU
Key=Software\Microsoft\Windows\CurrentVersion\Run
Action=create
RegistryValue
Type=string
Name=$(var.ProductName)
Value='[INSTALLLOCATION]$(var.FileOutput)'
KeyPath=yes
/
/RegistryKey
/Component
Component Id=RegistrySpecial Guid=*
Condition![CDATA[RUNWHENWINDOWSSTART 1]]/Condition
RegistryKey
Root=HKCU
Key=Software\Microsoft\Windows\CurrentVersion\Run
Action=create
RegistryValue
Type=string
Name=$(var.ProductName)
Value='[INSTALLLOCATION]$(var.FileOutput) -bootload'
KeyPath=yes
/
/RegistryKey
/Component
I thought * will generate GUID for each component. But how come it reports
that error? And it's always that ID. What is special about that ID? The
interesting thing is, if I delete one of the two components from the code,
the compile/link is fine. So it seems the root of the problem is that I'm
having these two components at the same time. Why I can't have these two
components at the same time? This is really a if-then-else scenario. Maybe I
shouldn't have two components to implement the logic? Is there any other way
to implement this?
Thanks.
/Brian
[WiX-users] Some text on progress dialog
We use Wix 3.0. In the progress dialog, there are some text showing during installation such as Starting services, Copying new files or Stopping services. I wonder if these text configurable based on different language? I found these string IDs and add the translation in each wxl files. But it doesn't seem working. It still always shows English no matter what language we choose. For instance, I have these in the WinUI_es-es.wxl: String Id=ProgressTextStartServicesIniciando servicios/String String Id=ProgressTextInstallFilesCopiando archivos nuevos/String String Id=ProgressTextStopServicesDeteniendo servicios/String String Id=ProgressTextCreateShortcutsCreando accesos directos/String String Id=ProgressTextRegisterProductRegistrando producto/String String Id=ProgressTextRollbackCleanupQuitando archivos de copia de seguridad/String But the Spanish installer still shows English. I doubt if these strings are from shell? Namely, they can't be customized based on the language? But I'm not sure. Let me know if you know it. Thanks. /Brian __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0: link error when using '*' in the component's GUID field
Thanks Blair.
Your code example makes sense. I'm going to try it.
However, you also said You may need to preserve RUNWHENWINDOWSSTART and
restore it during repairs
and/or small updates/minor upgrades so that the value doesn't change during
a repair. - I'm not quite getting this one.
We use major upgrade. I'm not sure this would apply. Could you tell me how to
preserve RUNWHENWINDOWSSTART and restore it?
Thanks.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Fri, October 30, 2009 5:54:06 PM
Subject: Re: [WiX-users] Wix 3.0: link error when using '*' in the component's
GUID field
Identity theft is always such a pain.
compone...@guid='*' is required to generate a stable guid. That means that
if the component's keypath didn't change, it is the same component. As a
result, both of your components, which share the exact same keypath, are the
same component as far as Windows Installer is concerned (they share the same
identity). The value isn't part of the keypath, unfortunately.
What you may consider doing instead is (since your components are currently
not transitive and are mutually exclusive) is something like this:
SetProperty Id='RunValueArgument' Value=' -bootload' Sequence='execute'
Before='WriteRegistryValues'![CDATA[RUNWHENWINDOWSSTART
1]]/SetProperty
Component Id=RunRegistry Guid=*
RegistryKey
Root=HKCU
Key=Software\Microsoft\Windows\CurrentVersion\Run
Action=create
RegistryValue
Type=string
Name=$(var.ProductName)
Value='[INSTALLLOCATION]$(var.FileOutput)[RunValueArgument]'
KeyPath=yes
/
/RegistryKey
/Component
You may need to preserve RUNWHENWINDOWSSTART and restore it during repairs
and/or small updates/minor upgrades so that the value doesn't change during
a repair.
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Friday, October 30, 2009 2:27 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Wix 3.0: link error when using '*' in the component's
GUID field
We use Wix 3.0.4805.0.
We run into a very strange link error: we have a component that uses * as
the GUID. But when we link it, it reports an error:
error LGHT0204 : ICE08: Component: RegistrySpecial has a duplicate GUID:
{A7C1768B-FF73-5DFC-8E76-E810E013F78A}
But I searched all of our source code, there is no GUID
{A7C1768B-FF73-5DFC-8E76-E810E013F78A} defined anywhere.
Here is the command line to compile and link it:
candle.exe -dRelease -out .wixobj file -arch x86 -ext ext dll files
myapp.wxs
light.exe -ext EXT_DLL_FILE -cultures:en-us -out myapp.msi -pdbout
PDB_FILE -loc LANG_FILE some .wixobj files
Basically, this is what we'd like to do:
there is an option called Start application when Windows starts. If the
end user select this option, we'll write the application's file path to a
registry entry; if the end user doesn't select this option, we'll also write
the entry with a parameter. The logic is just like this:
if (RUNWHENWINDOWSSTART) {
write registry with [PATH_TO_APP]
} else {
write registry with [PATH_TO_APP] -bootload
}
Here is the code:
Component Id=RegistryNormal Guid=*
ConditionRUNWHENWINDOWSSTART = 1/Condition
RegistryKey
Root=HKCU
Key=Software\Microsoft\Windows\CurrentVersion\Run
Action=create
RegistryValue
Type=string
Name=$(var.ProductName)
Value='[INSTALLLOCATION]$(var.FileOutput)'
KeyPath=yes
/
/RegistryKey
/Component
Component Id=RegistrySpecial Guid=*
Condition![CDATA[RUNWHENWINDOWSSTART 1]]/Condition
RegistryKey
Root=HKCU
Key=Software\Microsoft\Windows\CurrentVersion\Run
Action=create
RegistryValue
Type=string
Name=$(var.ProductName)
Value='[INSTALLLOCATION]$(var.FileOutput) -bootload'
KeyPath=yes
/
/RegistryKey
/Component
I thought * will generate GUID for each component. But how come it reports
that error? And it's always that ID. What is special about that ID? The
interesting thing is, if I delete one of the two components from the code,
the compile/link is fine. So it seems the root of the problem is that I'm
having these two components at the same time. Why I can't have these two
components at the same time? This is really a if-then-else scenario. Maybe I
shouldn't have two components to implement the logic? Is there any other way
to implement this?
Thanks.
/Brian
__
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users
Re: [WiX-users] Some language problem
Whoa, it works after I added 'CodePage=1252' attribute. Thank you so much.
One more question is, why do I need to specify the CodePage attribute for this
pt-BR language but not for other languages? Do you think I should add CodePage
for all of other languages?
Thanks again, Blair.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thursday, October 29, 2009 9:39:14 PM
Subject: Re: [WiX-users] Some language problem
Better yet would be 1252 instead of 860.
-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Thursday, October 29, 2009 5:24 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] Some language problem
In one of your wxl files for pt-BR, you need to change WixLocalization
Culture=pt-BR to WixLocalization Culture=pt-BR Codepage=860
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Thursday, October 29, 2009 4:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Some language problem
Hi Blair,
I appreciate your response.
I just tried the solution you provided. I've made a big progress:
when I compile each language, I added something like -cultures:fr-FR
because in our language file we have this line WixLocalization
Culture=fr-FR. Then I got the msi, I opened it with Orca. In
[Tools]-[Code Page...], I saw the code page is 1252. I suppose this is
correct?
Then I got the transforms for each language. And stuff in the mst in the
final msi.
The Spanish looks okay now, Great! German, French seem okay as well. But for
pt-BR(Brazil Portuguese), it is not correct. I then opened the pt-BR msi,
the code page is 0. Do you know why pt-BR doesn't work? Is it because pt-BR
isn't supported by Wix 3.0? I looked at the wix source
src\ext\UIExtension\wixlib folder, there is no pt-BR language file. I
actually got that file from Wix 2.0, is this okay or I shouldn't use the
file from 2.0?
If I shouldn't use it, where can I find a good pt-BR language file to use?
Thanks a lot.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thursday, October 29, 2009 1:00:49 AM
Subject: Re: [WiX-users] Some language problem
You will likely notice, if you open the MSI in Orca, that when you check the
codepage for the database it isn't the codepage you likely expected it to
be. The codepage used has to support the characters you intend to use. If
you don't set it, it defaults to 7-bit ASCII. Transforms should be able to
change the codepage of the database, so the problem is in your per-language
MSI creation.
Your .wxl files should supply the codepage you want/need for your MSIs if
you call light with the -Cultures switch (easiest way). You can add that
attribute to your WixLocalization element.
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Thursday, October 29, 2009 12:13 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Some language problem
We use Wix 3.0. The problem is, some Spanish characters don't show
correctly. instalación shows as instalaci?n.
Some background:
Our product requirement asks us to support multiple language MSI which
isn't supported officially by MSI. Someone posted some
trick(http://jpassing.wordpress.com/2007/06/14/authoring-multi-language-msi-
packages/ ) about how to get it work. I'd been through the whole way,
figured out the MST, transform, stuff the language in MSI etc. Anyways, I
got it work finally. We have a bootstrapper. The bootstrapper will show a
drop-down list of languages. The end user will select the language she
prefers. And then the bootstrapper will tell MSI which language it should
use. The whole thing works fine until yesterday.
As you know, there is no enough language files in Wix 3.0. So I get most of
the language files from Wix 2.0.
The problem:
Some strings don't display correctly in Spanish, Portuguese and Italian.
For example: the string WelcomeDlgTitle. The en-US one is like this
String Id=WelcomeDlgTitle{\WixUI_Font_Bigger}Welcome to the
[ProductName] Setup Wizard/String.
The Spanish one is String
Id=WelcomeDlgTitle{\WixUI_Font_Bigger}Asistente para la instalación de
[ProductName]/String
But when we run installer, we see Asistente para la instalaci?n de MyApp.
See the character ó shows as ?n? Since this is the first page of the
installer, so our team think this is a P1 bug.
Is this because I'm using the Wix 2.0 language file in Wix 3.0? But I don't
really have Wix 3.0 language files.
By the way, we have another product which uses Wix 2.0. And that product
uses the same language trick I'm using. But it doesn't have this problem. It
shows Asistente para la instalación de [ProductName] correctly.
I'm looking forward your kindly response
Re: [WiX-users] The untranslated string in uninstallation
Thanks Blair! Yes, that string shows when I click Remove from ARP. You said that come from the shell, what do you mean shell? You also said, ..is in the user's language, do you mean it is in the .wxl file? Then what is the string ID for it? I doesn't seem to find it. Thanks From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Thursday, October 29, 2009 9:47:25 PM Subject: Re: [WiX-users] The untranslated string in uninstallation Is that the string you see when you click Uninstall from Programs and Features (or ARP)? That comes from the shell, and is in the user's language. Is it the string you see when you run msiexec /x ProductCode or msiexec /x package-path.msi? That also comes in the user shell's language (it comes from Windows Installer itself), and it is shown even before any data about the product/package is read (the MSI file isn't even accessed yet). -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, October 29, 2009 5:30 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The untranslated string in uninstallation The string in uninstallation: Are you sure you want to uninstall this product? This string is always in English. Is it possible to translate it to other languages? I can't find it in the language file WixUI_en-us.wxl. Or it may be provided by MSI service? Thanks. /Brian __ Make your browsing faster, safer, and easier with the new Internet ExplorerR 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The untranslated string in uninstallation
Got it. Thanks Blair. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Friday, October 30, 2009 3:12:22 PM Subject: Re: [WiX-users] The untranslated string in uninstallation Right. It can't be customized. The most you can do is change the user's language (including logout-login) assuming the user's new chosen language is installed in the OS. We always operated under the assumption that understand the language of the Windows installation they have, so messages from the OS (like this one) would always be understood. Of course kiosk-type applications that won't be applicable, but Joe Public doesn't generally have permission to install/remove from kiosk terminals. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Friday, October 30, 2009 2:35 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] The untranslated string in uninstallation Hi Blair, Thanks for the info. Now I understand the string Are you sure you want to uninstall this product? is from shell. Does it mean we can't customize this string, correct? Thanks /Brian From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Friday, October 30, 2009 12:33:36 PM Subject: Re: [WiX-users] The untranslated string in uninstallation Shell in Windows = explorer.exe and/or something it owns/uses intimately (in this case, used to be the control panel applet. I don't know exactly which .dll the string would be in, but it is still Windows). User's language = the language that the user's shell is setup to use. In some SKUs of Windows you can add languages and can set each login to use a different language. This page explains some of that: http://msdn.microsoft.com/en-us/library/dd374098(VS.85).aspx -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Friday, October 30, 2009 11:16 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] The untranslated string in uninstallation Thanks Blair! Yes, that string shows when I click Remove from ARP. You said that come from the shell, what do you mean shell? You also said, ..is in the user's language, do you mean it is in the .wxl file? Then what is the string ID for it? I doesn't seem to find it. Thanks From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Thursday, October 29, 2009 9:47:25 PM Subject: Re: [WiX-users] The untranslated string in uninstallation Is that the string you see when you click Uninstall from Programs and Features (or ARP)? That comes from the shell, and is in the user's language. Is it the string you see when you run msiexec /x ProductCode or msiexec /x package-path.msi? That also comes in the user shell's language (it comes from Windows Installer itself), and it is shown even before any data about the product/package is read (the MSI file isn't even accessed yet). -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Thursday, October 29, 2009 5:30 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The untranslated string in uninstallation The string in uninstallation: Are you sure you want to uninstall this product? This string is always in English. Is it possible to translate it to other languages? I can't find it in the language file WixUI_en-us.wxl. Or it may be provided by MSI service? Thanks. /Brian __ Make your browsing faster, safer, and easier with the new Internet ExplorerR 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users
[WiX-users] Some language problem
We use Wix 3.0. The problem is, some Spanish characters don't show correctly.
instalación shows as instalaci?n.
Some background:
Our product requirement asks us to support multiple language MSI which isn't
supported officially by MSI. Someone posted some
trick(http://jpassing.wordpress.com/2007/06/14/authoring-multi-language-msi-packages/
) about how to get it work. I'd been through the whole way, figured out the
MST, transform, stuff the language in MSI etc. Anyways, I got it work finally.
We have a bootstrapper. The bootstrapper will show a drop-down list of
languages. The end user will select the language she prefers. And then the
bootstrapper will tell MSI which language it should use. The whole thing works
fine until yesterday.
As you know, there is no enough language files in Wix 3.0. So I get most of the
language files from Wix 2.0.
The problem:
Some strings don't display correctly in Spanish, Portuguese and Italian.
For example: the string WelcomeDlgTitle. The en-US one is like this String
Id=WelcomeDlgTitle{\WixUI_Font_Bigger}Welcome to the [ProductName] Setup
Wizard/String.
The Spanish one is String Id=WelcomeDlgTitle{\WixUI_Font_Bigger}Asistente
para la instalación de [ProductName]/String
But when we run installer, we see Asistente para la instalaci?n de MyApp.
See the character ó shows as ?n? Since this is the first page of the
installer, so our team think this is a P1 bug.
Is this because I'm using the Wix 2.0 language file in Wix 3.0? But I don't
really have Wix 3.0 language files.
By the way, we have another product which uses Wix 2.0. And that product uses
the same language trick I'm using. But it doesn't have this problem. It shows
Asistente para la instalación de [ProductName] correctly.
I'm looking forward your kindly response.
Thanks.
/Brian
__
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Some language problem
Hi Blair,
I appreciate your response.
I just tried the solution you provided. I've made a big progress:
when I compile each language, I added something like -cultures:fr-FR because
in our language file we have this line WixLocalization Culture=fr-FR.
Then I got the msi, I opened it with Orca. In [Tools]-[Code Page...], I saw
the code page is 1252. I suppose this is correct?
Then I got the transforms for each language. And stuff in the mst in the final
msi.
The Spanish looks okay now, Great! German, French seem okay as well. But for
pt-BR(Brazil Portuguese), it is not correct. I then opened the pt-BR msi, the
code page is 0. Do you know why pt-BR doesn't work? Is it because pt-BR isn't
supported by Wix 3.0? I looked at the wix source src\ext\UIExtension\wixlib
folder, there is no pt-BR language file. I actually got that file from Wix 2.0,
is this okay or I shouldn't use the file from 2.0?
If I shouldn't use it, where can I find a good pt-BR language file to use?
Thanks a lot.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thursday, October 29, 2009 1:00:49 AM
Subject: Re: [WiX-users] Some language problem
You will likely notice, if you open the MSI in Orca, that when you check the
codepage for the database it isn't the codepage you likely expected it to
be. The codepage used has to support the characters you intend to use. If
you don't set it, it defaults to 7-bit ASCII. Transforms should be able to
change the codepage of the database, so the problem is in your per-language
MSI creation.
Your .wxl files should supply the codepage you want/need for your MSIs if
you call light with the -Cultures switch (easiest way). You can add that
attribute to your WixLocalization element.
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Thursday, October 29, 2009 12:13 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Some language problem
We use Wix 3.0. The problem is, some Spanish characters don't show
correctly. instalación shows as instalaci?n.
Some background:
Our product requirement asks us to support multiple language MSI which
isn't supported officially by MSI. Someone posted some
trick(http://jpassing.wordpress.com/2007/06/14/authoring-multi-language-msi-
packages/ ) about how to get it work. I'd been through the whole way,
figured out the MST, transform, stuff the language in MSI etc. Anyways, I
got it work finally. We have a bootstrapper. The bootstrapper will show a
drop-down list of languages. The end user will select the language she
prefers. And then the bootstrapper will tell MSI which language it should
use. The whole thing works fine until yesterday.
As you know, there is no enough language files in Wix 3.0. So I get most of
the language files from Wix 2.0.
The problem:
Some strings don't display correctly in Spanish, Portuguese and Italian.
For example: the string WelcomeDlgTitle. The en-US one is like this
String Id=WelcomeDlgTitle{\WixUI_Font_Bigger}Welcome to the
[ProductName] Setup Wizard/String.
The Spanish one is String
Id=WelcomeDlgTitle{\WixUI_Font_Bigger}Asistente para la instalación de
[ProductName]/String
But when we run installer, we see Asistente para la instalaci?n de MyApp.
See the character ó shows as ?n? Since this is the first page of the
installer, so our team think this is a P1 bug.
Is this because I'm using the Wix 2.0 language file in Wix 3.0? But I don't
really have Wix 3.0 language files.
By the way, we have another product which uses Wix 2.0. And that product
uses the same language trick I'm using. But it doesn't have this problem. It
shows Asistente para la instalación de [ProductName] correctly.
I'm looking forward your kindly response.
Thanks.
/Brian
__
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
[WiX-users] The untranslated string in uninstallation
The string in uninstallation: Are you sure you want to uninstall this product? This string is always in English. Is it possible to translate it to other languages? I can't find it in the language file WixUI_en-us.wxl. Or it may be provided by MSI service? Thanks. /Brian __ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Hi Richard,
You're right. I did got some weird error by not using your approach for button
control event when I went back and forth among those dialog pages.
So I tried your approach, the errors were gone. However, I'm getting some other
new weird issues: every time I've to click the Next button or Back button 2
times to go next or go back, very strange. But after this two times of
clicking, I can go back and forth without problem. What's wrong?
You know, I took the code from WixUI_InstallDir.wxs and renamed it as
MyWixUI_InstallDir.wxs and used it in my project. I changed the code by using
your example, here is my code:
Publish Dialog=MyInstallDirDlg Control=Back Event=NewDialog
Value=LicenseAgreementDlg1/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=SetTargetPath
Value=[WIXUI_INSTALLDIR] Order=11/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=DoAction
Value=WixUIValidatePath Order=21/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=SpawnDialog
Value=InvalidDirDlg
Order=3![CDATA[WIXUI_INSTALLDIR_VALID1]]/Publish
!--My code start here--
Publish Dialog=MyInstallDirDlg Control=Next
Property=InstallDirNextDialog Value={}/
Publish Dialog=MyInstallDirDlg Control=Next
Property=InstallDirNextDialog
Value=MyAddedConfirmDlg![CDATA[WIXUI_INSTALLDIR_VALID=1 and
NEED_MIGRATE_SETTING=1]]/Publish
Publish Dialog=MyInstallDirDlg Control=Next
Property=InstallDirNextDialog
Value=VerifyReadyDlg![CDATA[WIXUI_INSTALLDIR_VALID=1 and
NEED_MIGRATE_SETTING1]]/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=NewDialog
Value=[InstallDirNextDialog] Order=4InstallDirNextDialog/Publish
!--My code end here--
Publish Dialog=MyInstallDirDlg Control=ChangeFolder
Property=_BrowseProperty Value=[WIXUI_INSTALLDIR] Order=11/Publish
Publish Dialog=MyInstallDirDlg Control=ChangeFolder Event=SpawnDialog
Value=BrowseDlg Order=21/Publish
As you can see, I changed the NewDialog(Next button) from one line to be 4
lines of code. Is it correct? But I don't know how come I have to click the
next button 2 times to go to the next page? Do I have to write all of those 4
conditions(Not A and Not B, A and B, Not A and B, A and Not B) as 4 publish
elements? In my case, I only care about two cases(A and B, A and Not B), is it
okay?
Thanks.
/Brian
From: Richard legal...@xmission.com
To: wix-users@lists.sourceforge.net
Sent: Wednesday, October 21, 2009 9:01:14 PM
Subject: Re: [WiX-users] How to detect files presence and conditionally show a
new added dialog page
In article 664797.8163...@web59804.mail.ac4.yahoo.com,
little.forest little.for...@ymail.com writes:
Additionally, you can't have more than one NewDialog control event
on a button, even if the conditions are mutually exclusive. - this is
interesting. Ca n you tell me where this fact comes from?
Found it.
Its in the docs for the ControlEvent table.
http://msdn.microsoft.com/en-us/library/aa368037(VS.85).aspx
The exception is that each control can publish a most one
NewDialog or one SpawnDialog event.
--
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/
Legalize Adulthood! http://legalizeadulthood.wordpress.com
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
__
Connect with friends from any web browser - no download required. Try the new
Yahoo! Canada Messenger for the Web BETA at
http://ca.messenger.yahoo.com/webmessengerpromo.php
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How is Control Condition supposed to work?
We use Wix 3.0. How is Control condition supposed to work? I've this code: Control Id=MigrateSettingsCheckBox Type=CheckBox X=20 Y=220 Width=290 Height=17 Property=MIGRATE_SETTING_CHECKBOX_VALUE CheckBoxValue=1 Text=Migrate settings from old version. Condition Action=showNot Installed and NEED_MIGRATE_SETTING/Condition /Control I'd like to see the checkbox shows if the condition is true, but not show if it's false. But the result is, no matter what, the checkbox always shows up. What's wrong? Thanks. __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How is Control Condition supposed to work?
Hi all, If you know how to show/hide a checkbox based on a property which is set on runtime, please let me know. We're eager to see the solution. Basically, we need to show the end user a dialog to tell them if they want to migrate their existing settings from old version to new. I'm having trouble to conditionally show a dialog(http://n2.nabble.com/How-to-detect-files-presence-and-conditionally-show-a-new-added-dialog-page-td3855938i20.html ). Well, we can show it, but we'll have to click the next button two times to get it move forward. Anyways, discussed with our team, we're even okay by just conditionally show/hide a checkbox. If this work, we can give up the conditionally showing dialog which cause much too much trouble. But conditionally show/hide checkout doesn't work either. Can you point out my problem? Here is the code: Control Id=MigrateSettingsCheckBox Type=CheckBox X=20 Y=220 Width=290 Height=17 Property=MIGRATE_SETTING_CHECKBOX_VALUE CheckBoxValue=1 Text=Migrate settings from old version. Condition Action=showNot Installed and NEED_MIGRATE_SETTING/Condition /Control The reason we have to conditionally show the checkbox is that, some of our users may not have old version of software, they probably just buy the new version. So there is no point to always show that checkbox. We have a custom action(DLL) can detect if the end user needs to migrate settings, and further set a property on runtime. This checkbox's show action is associated with that property. Does it make sense? Many many thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Tuesday, October 27, 2009 1:25:15 AM Subject: [WiX-users] How is Control Condition supposed to work? We use Wix 3.0. How is Control condition supposed to work? I've this code: Control Id=MigrateSettingsCheckBox Type=CheckBox X=20 Y=220 Width=290 Height=17 Property=MIGRATE_SETTING_CHECKBOX_VALUE CheckBoxValue=1 Text=Migrate settings from old version. Condition Action=showNot Installed and NEED_MIGRATE_SETTING/Condition /Control I'd like to see the checkbox shows if the condition is true, but not show if it's false. But the result is, no matter what, the checkbox always shows up. What's wrong? Thanks. __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Thanks a lot, Blair!
It works now. It seems the Order attribute is important. I also realized that
you added this line:
Publish Dialog=MyInstallDirDlg Control=Next
Property=WIXUI_INSTALLDIR_VALID Value=[WIXUI_INSTALLDIR_VALID] Order=3/
Can you tell me where Richard's blog is?
Thanks again. You saved our project.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Tuesday, October 27, 2009 2:14:10 PM
Subject: Re: [WiX-users] How to detect files presence and conditionally show a
new added dialog page
In Richard's blog post, he details the issue with Windows Installer not
recognizing that WIXUI_INSTALLDIR_VALID has had a value set/changed by the
custom action. You don't get anything happening because WI still thinks
WIXUI_INSTALLDIR_VALID != 1.
Publish Dialog=MyInstallDirDlg Control=Back Event=NewDialog
Value=LicenseAgreementDlg1/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=SetTargetPath
Value=[WIXUI_INSTALLDIR] Order=11/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=DoAction
Value=WixUIValidatePath Order=21/Publish
Publish Dialog=MyInstallDirDlg Control=Next
Property=WIXUI_INSTALLDIR_VALID Value=[WIXUI_INSTALLDIR_VALID]
Order=3/
Publish Dialog=MyInstallDirDlg Control=Next Event=SpawnDialog
Value=InvalidDirDlg
Order=4![CDATA[WIXUI_INSTALLDIR_VALID1]]/Publish
!--My code start here--
Publish Dialog=MyInstallDirDlg Control=Next
Property=InstallDirNextDialog Value={} Order=5/
Publish Dialog=MyInstallDirDlg Control=Next
Property=InstallDirNextDialog Value=MyAddedConfirmDlg
Order=6![CDATA[WIXUI_INSTALLDIR_VALID=1 and
NEED_MIGRATE_SETTING=1]]/Publish
Publish Dialog=MyInstallDirDlg Control=Next
Property=InstallDirNextDialog Value=VerifyReadyDlg
Order=7![CDATA[WIXUI_INSTALLDIR_VALID=1 and
NEED_MIGRATE_SETTING1]]/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=NewDialog
Value=[InstallDirNextDialog] Order=8InstallDirNextDialog/Publish
!--My code end here--
Publish Dialog=MyInstallDirDlg Control=ChangeFolder
Property=_BrowseProperty Value=[WIXUI_INSTALLDIR] Order=11/Publish
Publish Dialog=MyInstallDirDlg Control=ChangeFolder Event=SpawnDialog
Value=BrowseDlg Order=21/Publish
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Tuesday, October 27, 2009 1:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to detect files presence and conditionally show
a new added dialog page
I'm having trouble with this conditionally show a dialog based on a
property.
Now I can conditionally show the dialog. But when I click on the Next or
Back button, there is nothing happened. I'll have to click the button again
to go forward or back.
I took the code from WixUI_InstallDir.wxs and renamed it as
MyWixUI_InstallDir.wxs and used it in my project. I changed the code by
using your example, here is my code:
Publish Dialog=MyInstallDirDlg Control=Back Event=NewDialog
Value=LicenseAgreementDlg1/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=SetTargetPath
Value=[WIXUI_INSTALLDIR] Order=11/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=DoAction
Value=WixUIValidatePath Order=21/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=SpawnDialog
Value=InvalidDirDlg
Order=3![CDATA[WIXUI_INSTALLDIR_VALID1]]/Publish
!--My code start here--
Publish Dialog=MyInstallDirDlg Control=Next
Property=InstallDirNextDialog Value={}/
Publish Dialog=MyInstallDirDlg Control=Next
Property=InstallDirNextDialog
Value=MyAddedConfirmDlg![CDATA[WIXUI_INSTALLDIR_VALID=1 and
NEED_MIGRATE_SETTING=1]]/Publish
Publish Dialog=MyInstallDirDlg Control=Next
Property=InstallDirNextDialog
Value=VerifyReadyDlg![CDATA[WIXUI_INSTALLDIR_VALID=1 and
NEED_MIGRATE_SETTING1]]/Publish
Publish Dialog=MyInstallDirDlg Control=Next Event=NewDialog
Value=[InstallDirNextDialog] Order=4InstallDirNextDialog/Publish
!--My code end here--
Publish Dialog=MyInstallDirDlg Control=ChangeFolder
Property=_BrowseProperty Value=[WIXUI_INSTALLDIR] Order=11/Publish
Publish Dialog=MyInstallDirDlg Control=ChangeFolder Event=SpawnDialog
Value=BrowseDlg Order=21/Publish
Many thanks.
I'm looking forward your kindly help.
From: little.forest little.for...@ymail.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Tuesday, October 27, 2009 12:41:24 AM
Subject: Re: [WiX-users] How to detect files presence and conditionally show
a new added dialog page
Hi Richard,
You're right. I did got some weird error by not using your approach for
button control event when I went back and forth among those dialog pages.
So I tried your approach, the errors were gone. However, I'm getting some
other new weird issues: every time I've to click the Next button or Back
button 2 times to go next or go back, very strange. But after this two times
of clicking, I can go back and forth without
Re: [WiX-users] How is Control Condition supposed to work?
Thanks Blair. need to be set before you open the dialog - do you mean to set the property before the install wizard dialog? That must be on a very early stage. Currently, we have this code: CustomAction Id=SetSearchFolderProp Property=SETTING_FOLDERS_PROP Value=$(var.WIX_UPGRADE_SETTING_PARAMS) / Binary Id=DetectSettingMigrationBin SourceFile=DetectSetting.dll / CustomAction Id=DetectSettingMigrationCA BinaryKey=DetectSettingMigrationBin DllEntry=DetectSetting Execute=firstSequence / InstallUISequence Custom Action=SetSearchFolderProp After=AppSearch / Custom Action=DetectSettingMigrationCA After=SetSearchFolderProp / /InstallUISequence How can I schedule it to make sure it is set before I open the dialog? If while the dialog is open you want to change the visibility of the checkbox you subscribe to an event. - how to subscribe an event? Thanks. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, October 27, 2009 2:24:54 PM Subject: Re: [WiX-users] How is Control Condition supposed to work? If you want to use a condition to show or hide it, all properties used in that condition need to be set before you open the dialog (make sure that NEED_MIGRATE_SETTING is set by something not triggered by this dialog). If while the dialog is open you want to change the visibility of the checkbox you subscribe to an event. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Tuesday, October 27, 2009 1:59 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How is Control Condition supposed to work? Hi all, If you know how to show/hide a checkbox based on a property which is set on runtime, please let me know. We're eager to see the solution. Basically, we need to show the end user a dialog to tell them if they want to migrate their existing settings from old version to new. I'm having trouble to conditionally show a dialog(http://n2.nabble.com/How-to-detect-files-presence-and-conditionally-s how-a-new-added-dialog-page-td3855938i20.html ). Well, we can show it, but we'll have to click the next button two times to get it move forward. Anyways, discussed with our team, we're even okay by just conditionally show/hide a checkbox. If this work, we can give up the conditionally showing dialog which cause much too much trouble. But conditionally show/hide checkout doesn't work either. Can you point out my problem? Here is the code: Control Id=MigrateSettingsCheckBox Type=CheckBox X=20 Y=220 Width=290 Height=17 Property=MIGRATE_SETTING_CHECKBOX_VALUE CheckBoxValue=1 Text=Migrate settings from old version. Condition Action=showNot Installed and NEED_MIGRATE_SETTING/Condition /Control The reason we have to conditionally show the checkbox is that, some of our users may not have old version of software, they probably just buy the new version. So there is no point to always show that checkbox. We have a custom action(DLL) can detect if the end user needs to migrate settings, and further set a property on runtime. This checkbox's show action is associated with that property. Does it make sense? Many many thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Tuesday, October 27, 2009 1:25:15 AM Subject: [WiX-users] How is Control Condition supposed to work? We use Wix 3.0. How is Control condition supposed to work? I've this code: Control Id=MigrateSettingsCheckBox Type=CheckBox X=20 Y=220 Width=290 Height=17 Property=MIGRATE_SETTING_CHECKBOX_VALUE CheckBoxValue=1 Text=Migrate settings from old version. Condition Action=showNot Installed and NEED_MIGRATE_SETTING/Condition /Control I'd like to see the checkbox shows if the condition is true, but not show if it's false. But the result is, no matter what, the checkbox always shows up. What's wrong? Thanks. __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Hi Blair,
As what I mentioned, since our old 2.0 product's uninstaller deletes settings
but not remove the setting folder, there is a chance that the setting folder is
empty. So we can't detect folder but have to detect *.* by writing a DLL.
Anyways, I wrote a small dll and integrated it in the installer. But from the
log, the dll is never run. Could you please point out the problem? Here is the
Wix code:
Property Id=NEED_MIGRATE_SETTING Secure=yes/
Binary Id=DetectSettingMigrationBin SourceFile=DetectSM.dll /
CustomAction Id=DetectSettingMigrationCA
BinaryKey=DetectSettingMigrationBin DllEntry=DetectSM
Execute=firstSequence/
InstallExecuteSequence
Custom Action=DetectSettingMigrationCA After=AppSearch /
/InstallExecuteSequence
In the dll, for testing purpose, I just set the property NEED_MIGRATE_SETTING
as 1 for now. But I checked the log, the dll itself is never run.
Thanks.
/Brian.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Tuesday, October 20, 2009 7:27:41 PM
Subject: Re: [WiX-users] How to detect files presence and conditionally show a
new added dialog page
Can you live with the existence (or lack thereof) of those two settings
directories? Does it matter if they are empty or not? I would assume that if
the 3.0 one didn't exist but the 2.0 one does, you have a better than even
chance you have data to upgrade. Anytime you can use a built-in custom
action instead of supplying your own, you tend to improve reliability.
However, you can add as many custom actions (and custom action binaries)
into your installation package as you wish, up to the size limit of the MSI
file (not that you would ever want an MSI file that big).
I assume your AppData property is the APPDATA environment variable. If
not, change my [%AppData]\ and ensure that the property is defined before
the AppSearch action. If it is defined in your Directory table, those
properties are not populated until CostFinalize. Note that if Windows
Installer defines a path, it always includes the trailing backslash ('\').
If you supply paths via your own custom action, you should do the same.
Property Id=SETTINGS_20_EXIST Secure=yes
DirectorySearch Id=[%AppData]\MyCompany\MyApp 2.0 Depth=0/
/Property
Property Id=SETTINGS_30_EXIST Secure=yes
DirectorySearch Id=[%AppData]\MyCompany\MyApp 3.0 Depth=0/
/Property
Property Id=NEED_UPGRADE_SETTING Secure=yes/
CustomAction Id=SetNeedUpgradeSetting Property=NEED_UPGRADE_SETTING
Value=1 Execute=firstSequence/
InstallUISequence
Custom Action=SetNeedUpgradeSetting After=AppSearchSETTINGS_20_EXIST
AND NOT SETTINGS_30_EXIST/Custom
/InstallUISequence
If you can't use mere absence/presence of the folders for your detection
routine, don't use any of my code (except for the secure property
declaration of NEED_UPDRADE_SETTING) and instead set NEED_UPDRADE_SETTING in
your DLL action. Call your action with no condition in your
InstallUISequence where I call SetNeedUpgradeSetting.
Now, on to the InstallExecuteSequence. I am assuming that your confirmation
dialog (MyDlg) has a check box that is associated with the property
REALLY_NEED_UPGRADE_SETTING (which sets it to the value 1 if the box is
checked). What is your default? Also, if the UI is bypassed, what should the
assumed value be? I hope it is the same (checked by default, assumed checked
if never shown). That makes your logic easier.
You will need to make sure your REALLY_NEED_UPGRADE_SETTING property is also
secure. I will assume it is also checked by default. If you are using your
DLL instead of simple folder detection you should also set it to
Execute=firstSequence.
Property Id=REALLY_NEED_UPGRADE_SETTING Secure=yes Value=1/!--
remove 'Value=1' but leave the rest if migrating settings is NOT the
default action--
InstallExecuteSequence
Custom Action=SetNeedUpgradeSetting After=AppSearchSETTINGS_20_EXIST
AND NOT SETTINGS_30_EXIST/Custom!--Note that this is identical to
InstallUISequence. That is by design.--
Custom Action=DoSettingUpgrade Before=InstallFinalizeNOT Installed
AND REALLY_NEED_UPGRADE_SETTING AND NEED_UPGRADE_SETTING/Custom!-- you
may consider removing NOT Installed AND from this condition. Then repairs
and minor upgrades will restore your 3.0 settings from the 2.0 ones if they
are lost--
/InstallExecuteSequence
If your default action and your opt-in/-out experience are different, you
will have a bit more complicated logic story, but I will leave that unless
you need help with that.
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Tuesday, October 20, 2009 5:40 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to detect files presence and conditionally show
a new added dialog page
Hi Blair,
Thank you so much. I really appreciate your detailed reply. The code example
you provided is clear and neat.
Basically, we'd like
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Aha, you're right. I didn't schedule the CA in InstallUISequence.
Sorry.
After add it in InstallUISequence, it seems working.
Thanks and have a good weekend!
/Brian
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Friday, October 23, 2009 5:34:05 PM
Subject: Re: [WiX-users] How to detect files presence and conditionally show a
new added dialog page
Did you try scheduling the custom action in both InstallUISequence as well
as InstallExecuteSequence?
-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Friday, October 23, 2009 5:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to detect files presence and conditionally show
a new added dialog page
Hi Blair,
As what I mentioned, since our old 2.0 product's uninstaller deletes
settings but not remove the setting folder, there is a chance that the
setting folder is empty. So we can't detect folder but have to detect *.* by
writing a DLL. Anyways, I wrote a small dll and integrated it in the
installer. But from the log, the dll is never run. Could you please point
out the problem? Here is the Wix code:
Property Id=NEED_MIGRATE_SETTING Secure=yes/
Binary Id=DetectSettingMigrationBin SourceFile=DetectSM.dll /
CustomAction Id=DetectSettingMigrationCA
BinaryKey=DetectSettingMigrationBin DllEntry=DetectSM
Execute=firstSequence/
InstallExecuteSequence
Custom Action=DetectSettingMigrationCA After=AppSearch /
/InstallExecuteSequence
In the dll, for testing purpose, I just set the property
NEED_MIGRATE_SETTING as 1 for now. But I checked the log, the dll itself is
never run.
Thanks.
/Brian.
From: Blair os...@live.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Tuesday, October 20, 2009 7:27:41 PM
Subject: Re: [WiX-users] How to detect files presence and conditionally show
a new added dialog page
Can you live with the existence (or lack thereof) of those two settings
directories? Does it matter if they are empty or not? I would assume that if
the 3.0 one didn't exist but the 2.0 one does, you have a better than even
chance you have data to upgrade. Anytime you can use a built-in custom
action instead of supplying your own, you tend to improve reliability.
However, you can add as many custom actions (and custom action binaries)
into your installation package as you wish, up to the size limit of the MSI
file (not that you would ever want an MSI file that big).
I assume your AppData property is the APPDATA environment variable. If
not, change my [%AppData]\ and ensure that the property is defined before
the AppSearch action. If it is defined in your Directory table, those
properties are not populated until CostFinalize. Note that if Windows
Installer defines a path, it always includes the trailing backslash ('\').
If you supply paths via your own custom action, you should do the same.
Property Id=SETTINGS_20_EXIST Secure=yes
DirectorySearch Id=[%AppData]\MyCompany\MyApp 2.0 Depth=0/
/Property
Property Id=SETTINGS_30_EXIST Secure=yes
DirectorySearch Id=[%AppData]\MyCompany\MyApp 3.0 Depth=0/
/Property
Property Id=NEED_UPGRADE_SETTING Secure=yes/
CustomAction Id=SetNeedUpgradeSetting Property=NEED_UPGRADE_SETTING
Value=1 Execute=firstSequence/
InstallUISequence
Custom Action=SetNeedUpgradeSetting After=AppSearchSETTINGS_20_EXIST
AND NOT SETTINGS_30_EXIST/Custom
/InstallUISequence
If you can't use mere absence/presence of the folders for your detection
routine, don't use any of my code (except for the secure property
declaration of NEED_UPDRADE_SETTING) and instead set NEED_UPDRADE_SETTING in
your DLL action. Call your action with no condition in your
InstallUISequence where I call SetNeedUpgradeSetting.
Now, on to the InstallExecuteSequence. I am assuming that your confirmation
dialog (MyDlg) has a check box that is associated with the property
REALLY_NEED_UPGRADE_SETTING (which sets it to the value 1 if the box is
checked). What is your default? Also, if the UI is bypassed, what should the
assumed value be? I hope it is the same (checked by default, assumed checked
if never shown). That makes your logic easier.
You will need to make sure your REALLY_NEED_UPGRADE_SETTING property is also
secure. I will assume it is also checked by default. If you are using your
DLL instead of simple folder detection you should also set it to
Execute=firstSequence.
Property Id=REALLY_NEED_UPGRADE_SETTING Secure=yes Value=1/!--
remove 'Value=1' but leave the rest if migrating settings is NOT the
default action--
InstallExecuteSequence
Custom Action=SetNeedUpgradeSetting After=AppSearchSETTINGS_20_EXIST
AND NOT SETTINGS_30_EXIST/Custom!--Note that this is identical to
InstallUISequence. That is by design.--
Custom Action=DoSettingUpgrade Before=InstallFinalizeNOT Installed
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Wow, you found it. Many thanks Richard. The annoying thing is that it will *appear* to work until it doesn't and there's no unifying principle as to when it will work and when it won't. Its a little more work to do things through the property, but it is guaranteed to work every single time that way. - yes, it's really annoying. From: Richard legal...@xmission.com To: wix-users@lists.sourceforge.net Sent: Wednesday, October 21, 2009 9:01:14 PM Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page In article 664797.8163...@web59804.mail.ac4.yahoo.com, little.forest little.for...@ymail.com writes: Additionally, you can't have more than one NewDialog control event on a button, even if the conditions are mutually exclusive. - this is interesting. Ca n you tell me where this fact comes from? Found it. Its in the docs for the ControlEvent table. http://msdn.microsoft.com/en-us/library/aa368037(VS.85).aspx The exception is that each control can publish a most one NewDialog or one SpawnDialog event. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Before=InstallFinalizeNOT Installed AND REALLY_NEED_UPGRADE_SETTING AND NEED_UPGRADE_SETTING/Custom!-- you may consider removing NOT Installed AND from this condition. Then repairs and minor upgrades will restore your 3.0 settings from the 2.0 ones if they are lost-- /InstallExecuteSequence If your default action and your opt-in/-out experience are different, you will have a bit more complicated logic story, but I will leave that unless you need help with that. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Tuesday, October 20, 2009 5:40 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page Hi Blair, Thank you so much. I really appreciate your detailed reply. The code example you provided is clear and neat. Basically, we'd like to do these: 1. Detect if we need to do a setting migration: look into [AppData]\MyCompany\MyApp 3.0 folder and [AppData]\MyCompany\MyApp 2.0 folder. If there is nothing in 3.0 folder(it means the user never install the 3.0 version) and there is something in 2.0 folder(it means the user ever used 2.0 version), then we should do setting upgrade. We'll need to set a property. 2. If the property is set, then we'll need to do setting upgrade. We'll show a new page after InstallDirDlg and before VerifyReadyDlg. In this page, we'll say We have detected you have 2.0 settings. Do you want to upgrade these settings to 3.0?, and provide a checkbox. If the property is not set, we do not show this setting migration page. 3. After installation but before it's finished, based on the property, we'll either run a small program to migrate settings, or do nothing. So from these description, hopefully you've got our logic: we need to detect-set property-show message on GUI-do setting migration. Our setting folder structure is a bit of complicated. The setting folder may contain files(like settings.xml, or ui.xml), or may contain user's login(like james or linda). So when doing detection, we really couldn't count on a specific file. What we really need is to detect *.* which isn't supported by MSI. So I guess I'll have to write a DLL to do the detection work? Inside the DLL, I'll look into the source and destination folder and set property, right? For display on GUI, with your code example and a lot of google searching and trying, I've got it work. Here is the code for dialog sequence, please point out errors if you find there is any: Publish Dialog=MyInstallDirDlg Control=Next Event=NewDialog Value=MyDlg Order=4![CDATA[WIXUI_INSTALLDIR_VALID=1 and NEED_UPGRADE_SETTING=1]]/Publish Publish Dialog=MyInstallDirDlg Control=Next Event=NewDialog Value=VerifyReadyDlg Order=4![CDATA[WIXUI_INSTALLDIR_VALID=1 and NEED_UPGRADE_SETTING1]]/Publish Publish Dialog=MyDlg Control=Back Event=NewDialog Value=MyInstallDirDlg Order=1NOT Installed/Publish Publish Dialog=MyDlg Control=Back Event=NewDialog Value=MaintenanceTypeDlg Order=2Installed/Publish Publish Dialog=MyDlg Control=Next Event=NewDialog Value=VerifyReadyDlg Order=1NOT Installed/Publish Publish Dialog=MyDlg Control=Next Event=NewDialog Value=MaintenanceTypeDlg Order=2Installed/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=MyDlg Order=1NOT Installed and NEED_UPGRADE_SETTING/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=MyInstallDirDlg Order=1NOT Installed and NOT NEED_UPGRADE_SETTING/Publish I made some testing, it seems working: if I explicitly set NEED_UPGRADE_SETTING property in my code, I did see the message page; if I don't, then I didn't see the page. So it's good. So my goal is to look into the DLL which can detect if need to migrate setting and set the property. I'll get on it. But there are still two things I'm not sure: 1. As you know, we have an EXE program to handle the setting migration. Is it okay to include both the detection DLL and the upgrade program EXE in one installer? Here is our setting upgrade program code part: Binary Id=SettingUpgraderApp SourceFile=upgrade_settings.exe/ CustomAction Id=DoSettingUpgrade BinaryKey=SettingUpgraderApp ExeCommand='-run param1 param2' Execute=deferred Return=check HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=DoSettingUpgrade Before=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence 2. How to make the detection happen before the actual setting migration program? Am I doing the right thing? Or am I in the right direction? Please let me know. Thanks again, /Brian From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Hi Richard,
Thanks for your reply.
Additionally, you can't have more than one NewDialog control event on a
button, even if the conditions are mutually exclusive. - this is interesting.
Can you tell me where this fact comes from? I googled, it's not mentioned in
Wix or MSI. Also, I found this post Customized UI's for
WiX(http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html ).
There is code like this - you see Niel Sleightholm does have two NewDialog
control event for one button:
Publish Dialog=CustomizeDlg Control=Back Event=NewDialog
Value=MaintenanceTypeDlg
Order=1WixUI_InstallMode = Change/Publish
Publish Dialog=CustomizeDlg Control=Back Event=NewDialog
Value=SetupTypeDlg
Order=2WixUI_InstallMode = InstallCustom/PublishThanks.
/Brian
From: Richard legal...@xmission.com
To: wix-users@lists.sourceforge.net
Sent: Tuesday, October 20, 2009 9:44:55 PM
Subject: Re: [WiX-users] How to detect files presence and conditionally show a
new added dialog page
In article 414331.22649...@web59815.mail.ac4.yahoo.com,
little.forest little.for...@ymail.com writes:
Hmm, can you tell me how to use AppSearch to locate folders?
Use Property with a nested DirectorySearch
Use type 19 CA to set properties [...]
As pointed out by others, I was wrong in saying type 19, its type 51
(set property) as already mentioned.
Not every CA requires a DLL or EXE -- only DLL/EXE CAs need them. WiX
exposes a set property CA with SetProperty.
You can reuse your upgrade_settings.exe program, but you may find that
its more trouble than its worth because this means creating a custom
action in code and interacting with this external utility to set
properties in the MSI. You might find it easier to have this upgrade
settings utility invoke msiexec on your MSI with command-line
arguments to set properties for the installation, essentially using
the upgrade settings utility as a bootstrapper.
And the last question, to use condition on events to determine dialogs shown
in a wizard, is it some like this?
Publish Dialog=MyDlg Control=Back Event=NewDialog Value=M
yInstallDirDlg Order=1NOT Installed and and REALLY_NEED_UPGRADE_SETTING/Pu
blish
Yes, but be careful about conditions and the fact that you need to
populate those conditions on the Next button *and* the back button
*and* you need to make sure that the conditions are setup properly so
that dialog transitions are managed properly. Additionally, you can't
have more than one NewDialog control event on a button, even if the
conditions are mutually exclusive. You'll get weird behavior if you
try this.
The way to manage complex dialog transitions is to use a property to
hold the name of the dialog you wish to display and conditionally set
this property to the right value. Then transition to the dialog named
by the property:
For instance, suppose the transition table for the Back button on
MyDlg looks like this:
Target Dialog Condition
Dialog1 NOT A AND NOT B
Dialog2 A AND NOT B
Dialog3 A AND B
Dialog4 NOT A AND B
The following Publish events show how to implement this logic with a
single NewDialog event on the Back button of MyDlg:
!-- go to Dialog1 by default --
Publish Dialog=MyDlg Control=Back
Property=BackDialog Value=Dialog1/
Publish Dialog=MyDlg Control=Back
Property=BackDialog Value=Dialog2A AND NOT B/Publish
Publish Dialog=MyDlg Control=Back
Property=BackDialog Value=Dialog3A AND B/Publish
Publish Dialog=MyDlg Control=Back
Property=BackDialog Value=Dialog4NOT A AND B/Publish
Publish Dialog=MyDlg Control=Back
Event=NewDialog Value=[BackDialog]/
Note that the first set property event has no condition, guaranteeing
that the transition is always well defined. You can also null out the
property and then take the NewDialog transition only when the property
is non-empty:
!-- go to Dialog1 by default --
Publish Dialog=MyDlg Control=Back Property=BackDialog Value={}/
Publish Dialog=MyDlg Control=Back
Property=BackDialog Value=Dialog1NOT A AND NOT B/Publish
Publish Dialog=MyDlg Control=Back
Property=BackDialog Value=Dialog2A AND NOT B/Publish
Publish Dialog=MyDlg Control=Back
Property=BackDialog Value=Dialog3A AND B/Publish
Publish Dialog=MyDlg Control=Back
Property=BackDialog Value=Dialog4NOT A AND B/Publish
Publish Dialog=MyDlg Control=Back
Event=NewDialog Value=[BackDialog]BackDialog/Publish
--
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/
Legalize Adulthood! http://legalizeadulthood.wordpress.com
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take
Re: [WiX-users] Beginner's Question on Multi Language Installer
Hi Markus, I found this site is useful: http://blogs.technet.com/alexshev/pages/from-msi-to-wix.aspx I ever made a post Where to get more WiX knowledge(http://n2.nabble.com/Where-to-get-more-WiX-knowledge-td3529191.html#a3529191 ). But I was told to read MSI document. Well I even printed out that 1000+ pages document. But life is short, it's not easy to read them all. So whenever I want to do something either easy or complex, I'm having hard times. The fact is, in my company at least, the installer development work isn't considered important or advanced. People always told me that installer is easy, just install some files, right?. Plus, installer work just takes 30% to 40% of my time. I'll have to have most of my time work on other development tasks. So there is really no much time to sharp my Wix skills. I guess this is true in most of other companies. So a good documentation is really needed. I hope Wix community could come up with a detailed documentation with code examples, details, and explain why it works that way. From: Markus KARG markus.k...@gmx.net To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wednesday, October 21, 2009 11:18:00 AM Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Well, frankly spoken that (really huge) tutorial is in part outdated, false and overly complex to understand, and it does things without explaining their intension or details in some chapters (what really confuses beginners). So after reading it two times I gave up and posted my question here... Thanks Markus -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Mittwoch, 21. Oktober 2009 16:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Beginner's Question on Multi Language Installer Unfortunately, no. Have you read through the WiX tutorial http://wix.sf.net/tutorial? I thought it had a nice section on languages in MSIs. virtually, Rob Mensching - RobMensching.com LLC http://robmensching.com On Wed, Oct 21, 2009 at 3:13 AM, mrtn mrtn.frederik...@gmail.com wrote: In stead of a bootstrapper - selecting the wanted transform - is it possible for the .msi file itself to select a transform file? Maybe in a C++ CA? Blair-2 wrote: You get German since that is the first one in your list of Cultures. MSI has never officially supported the scenario you describe directly. You are perfectly free to create per-language transforms and use an .EXE file to install your MSI with those transforms (the supported way). There are some who have had success with embedding those same transforms based on a particular naming convention and having them auto-selected by the OS (not supported, but I'm told it works). There may or may not be issues with generating working MSP files if you use those transforms (you may have to mess with the transform applicability rules of the patch-supplied transforms depending on what the original language transforms did). You may be able to use the instance transform related tags in WiX, but I have never tried that so I don't know what gotchas you may find that way. Otherwise you may be able to link each language separately into .wixout files, generate your transforms from those, and bind the baseline wixout into the MSI you subsequently apply each MST to. -Original Message- From: Markus KARG [mailto:markus.k...@gmx.net] Sent: Tuesday, October 20, 2009 12:06 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Beginner's Question on Multi Language Installer Hello Everybody, I am new to both, MSI technology in general and the WiX product in particular, but I have some experience with some old InstallShield products (pre-MSI-age). InstallShield allowed me to simply add translated strings for lots of languages, so one single setup.exe contained the installer in multi languages. This was very smart since I was able to send the same setup.exe to any country of the world. Now I want to write an installer with WiX that is also multi language (I don't want to have lots of setup.msi files, but only a single one). I wrote several .wxl files and linked them together using a line like this one: light.exe -cultures:de,neutral;fr,neutral;en,neutral;neutral -loc de.wxl -loc fr.wxl -loc en.wxl -loc neutral.wxl Setup.wixobj (While actually told nowhere, it seems that neutral.wxl must contain ' .culture=. ' [i. e. empty string] to indicate that it is the neutral culture. I found out that by trial and error when adding the neutral fallback to each culture). What I expect to get from light.exe is one single .msi file containing all four
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Thanks for your reply, Richard. Hmm, can you tell me how to use AppSearch to locate folders? Use type 19 CA to set properties - I guess you mean I'll need a dll or exe to detect and set the property, right? If so, is it possible that I can reuse my existing setting upgrade program? I already have a small program to handle setting upgrade - it accepts parameters to run like this upgrade_settings.exe -run param1 param2. Can I run it something like upgrade_settings.exe -detect param1 param2 just for detection reason? How can I make sure this detection run is before the actual setting upgrade running? I've a feeling that, for one program, we'd better not to run it twice in one installer. Or, even I can write another program to do the detection work, but how can I sequence these two apps to make the detection one run first? Maybe I'm wrong, but I worry about the program sequencing. Currently, I have these code: Binary Id=SettingUpgraderApp SourceFile=upgrade_settings.exe/ CustomAction Id=DoSettingUpgrade BinaryKey=SettingUpgraderApp ExeCommand='-run param1 param2' Execute=deferred Return=check HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=DoSettingUpgrade Before=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence If, say, add the detection, can I do this? CustomAction Id=SettingUpgradeDetection BinaryKey=SettingUpgraderApp ExeCommand='-detect param1 param2' Execute=deferred Return=check HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=SettingUpgradeDetection Before=DoSettingUpgradeNOT Installed and REALLY_NEED_UPGRADE_SETTING/Custom /InstallExecuteSequence And the last question, to use condition on events to determine dialogs shown in a wizard, is it some like this? Publish Dialog=MyDlg Control=Back Event=NewDialog Value=MyInstallDirDlg Order=1NOT Installed and and REALLY_NEED_UPGRADE_SETTING/Publish Thanks! From: Richard legal...@xmission.com To: wix-users@lists.sourceforge.net Sent: Monday, October 19, 2009 6:52:11 PM Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page Use AppSearch to locate folders. Use type 19 CA's (property set) to set properties based on conditions Use conditions on events to determine dialogs shown in a wizard sequence, or a condition on the dialog action in the UI sequence to conditionally display dialogs. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Thanks Blair. Frankly, I'm not getting what you just said. I'm afraid that I couldn't translate your instructions to be actual code and make it work. Is it possible to provide some step by step instructions? I'd just like it more specific. (Even I've being dealt with Wix for more then 10 months, I'd say I'm still a newbie. Forgive me, please.) Thanks anyway. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, October 20, 2009 3:05:32 PM Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page Type 19 is CustomAction Property='PROPID' Value='My Value [WITHPROPERTIES] if needed'/ You schedule it in the sequence tables like any other custom action, including using conditions. And, yes, on your conditions to determine dialogs question. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Tuesday, October 20, 2009 12:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page Thanks for your reply, Richard. Hmm, can you tell me how to use AppSearch to locate folders? Use type 19 CA to set properties - I guess you mean I'll need a dll or exe to detect and set the property, right? If so, is it possible that I can reuse my existing setting upgrade program? I already have a small program to handle setting upgrade - it accepts parameters to run like this upgrade_settings.exe -run param1 param2. Can I run it something like upgrade_settings.exe -detect param1 param2 just for detection reason? How can I make sure this detection run is before the actual setting upgrade running? I've a feeling that, for one program, we'd better not to run it twice in one installer. Or, even I can write another program to do the detection work, but how can I sequence these two apps to make the detection one run first? Maybe I'm wrong, but I worry about the program sequencing. Currently, I have these code: Binary Id=SettingUpgraderApp SourceFile=upgrade_settings.exe/ CustomAction Id=DoSettingUpgrade BinaryKey=SettingUpgraderApp ExeCommand='-run param1 param2' Execute=deferred Return=check HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=DoSettingUpgrade Before=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence If, say, add the detection, can I do this? CustomAction Id=SettingUpgradeDetection BinaryKey=SettingUpgraderApp ExeCommand='-detect param1 param2' Execute=deferred Return=check HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=SettingUpgradeDetection Before=DoSettingUpgradeNOT Installed and REALLY_NEED_UPGRADE_SETTING/Custom /InstallExecuteSequence And the last question, to use condition on events to determine dialogs shown in a wizard, is it some like this? Publish Dialog=MyDlg Control=Back Event=NewDialog Value=MyInstallDirDlg Order=1NOT Installed and and REALLY_NEED_UPGRADE_SETTING/Publish Thanks! From: Richard legal...@xmission.com To: wix-users@lists.sourceforge.net Sent: Monday, October 19, 2009 6:52:11 PM Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page Use AppSearch to locate folders. Use type 19 CA's (property set) to set properties based on conditions Use conditions on events to determine dialogs shown in a wizard sequence, or a condition on the dialog action in the UI sequence to conditionally display dialogs. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event
Re: [WiX-users] Heat and GUIDs
I also run into a GUID and * related issue:
I have all of the components use * as the GUID. For one specific component,
however, I always get an xxx component has a duplicate GUID: {...} when I use
Visual Studio 2008 to compile it. I'll have to give it an actual GUID, then it
compiles okay. Interestingly, in our build server, we don't have this
problem(we use command line compiler in build server). Is there any chance that
Wix for Visual Studio 2008 has a bug regarding this GUID generation?
From: Daniel Hughes daniel.hug...@tait.co.nz
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Tuesday, October 20, 2009 4:05:13 PM
Subject: Re: [WiX-users] Heat and GUIDs
the help about -ag says: autogenerate component guids at compile time
I assumed this would mean that each time it is compiled a new guid was
generated.
If in fact the guid is static as you say, it must be recorded somewhere
(all the file has in it is *), ie wix would have to know what guid was
used for that component last time we created an installer and reuse it.
My question is how would it know? or more simply where is the guid recorded?
Brian Rogers wrote:
Hey Daniel,
Are you sure you are getting NEW GUIDs when using the * (-ag switch in
heat.exe)? These should actually be static.
Thanks,
Brian Rogers
Intelligence removes complexity. - Me
http://blogs.msdn.com/icumove -- NEW
On Tue, Oct 20, 2009 at 2:47 PM, Daniel Hughes
daniel.hug...@tait.co.nzwrote:
If I use heat to harvest the contents of a folder, I can set it to
either generated GUIDs then or at compile time, or by default to put in
place holders.
However if I set it to generate GUIDs then, I will get a different GUID
each time I run HEAT.
If I set it to generate GUIDs at compile time I will get a different
GUID each time I build my installer.
My question is, do my components need to have the same GUID in each
installer a produce. If so does this mean that HEAT is a tool which I
can only use once to harvest the XML and then from then on I must edit
it manually (so I don't lose the GUIDs).
Cheers,
Daniel
===
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
===
This email, including any attachments, is only for the intended
addressee. It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
===
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page
Value=1 Execute=firstSequence/ Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=MyDlg Order=1NOT Installed and NEED_UPGRADE_SETTING/Publish Publish Dialog=MyDlg Control=Next Event=NewDialog Value=MyInstallDirDlg Order=1NOT Installed and NEED_UPGRADE_SETTING/Publish Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=MyInstallDirDlg Order=1Installed or NOT NEED_UPGRADE_SETTING/Publish Publish Dialog=MyInstallDirDlg Control=Last Event=NewDialog Value=MyDlg Order=1NOT Installed and NEED_UPGRADE_SETTING/Publish Publish Dialog=MyInstallDirDlg Control=Last Event=NewDialog Value=WelcomeDlg Order=1Installed or NOT NEED_UPGRADE_SETTING/Publish InstallUISequence Custom Action=SetMyProperty Before=WelcomeDlgNEED_UPGRADE_SETTING/Custom /InstallUISequence InstallExecuteSequence Custom Action=SetMyProperty Before=WelcomeDlgNEED_UPGRADE_SETTING/Custom /InstallExecuteSequence If you can describe the logic (including UI) you are looking for and a way to use file/directory/registry/MSI component searches to determine your need to perform the upgrade, we can help you craft that. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Tuesday, October 20, 2009 3:23 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page Thanks Blair. Frankly, I'm not getting what you just said. I'm afraid that I couldn't translate your instructions to be actual code and make it work. Is it possible to provide some step by step instructions? I'd just like it more specific. (Even I've being dealt with Wix for more then 10 months, I'd say I'm still a newbie. Forgive me, please.) Thanks anyway. From: Blair os...@live.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Tuesday, October 20, 2009 3:05:32 PM Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page Type 19 is CustomAction Property='PROPID' Value='My Value [WITHPROPERTIES] if needed'/ You schedule it in the sequence tables like any other custom action, including using conditions. And, yes, on your conditions to determine dialogs question. -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Tuesday, October 20, 2009 12:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page Thanks for your reply, Richard. Hmm, can you tell me how to use AppSearch to locate folders? Use type 19 CA to set properties - I guess you mean I'll need a dll or exe to detect and set the property, right? If so, is it possible that I can reuse my existing setting upgrade program? I already have a small program to handle setting upgrade - it accepts parameters to run like this upgrade_settings.exe -run param1 param2. Can I run it something like upgrade_settings.exe -detect param1 param2 just for detection reason? How can I make sure this detection run is before the actual setting upgrade running? I've a feeling that, for one program, we'd better not to run it twice in one installer. Or, even I can write another program to do the detection work, but how can I sequence these two apps to make the detection one run first? Maybe I'm wrong, but I worry about the program sequencing. Currently, I have these code: Binary Id=SettingUpgraderApp SourceFile=upgrade_settings.exe/ CustomAction Id=DoSettingUpgrade BinaryKey=SettingUpgraderApp ExeCommand='-run param1 param2' Execute=deferred Return=check HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=DoSettingUpgrade Before=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence If, say, add the detection, can I do this? CustomAction Id=SettingUpgradeDetection BinaryKey=SettingUpgraderApp ExeCommand='-detect param1 param2' Execute=deferred Return=check HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=SettingUpgradeDetection Before=DoSettingUpgradeNOT Installed and REALLY_NEED_UPGRADE_SETTING/Custom /InstallExecuteSequence And the last question, to use condition on events to determine dialogs shown in a wizard, is it some like this? Publish Dialog=MyDlg Control=Back Event=NewDialog Value=MyInstallDirDlg Order=1NOT Installed and and REALLY_NEED_UPGRADE_SETTING/Publish Thanks! From: Richard legal...@xmission.com To: wix-users@lists.sourceforge.net Sent: Monday, October 19, 2009 6:52:11 PM Subject: Re: [WiX-users] How to detect files presence and conditionally show a new added dialog page Use AppSearch to locate folders. Use type 19 CA's (property set) to set properties
[WiX-users] How to add FilesInUse support
We use WiX 3.0. We have a problem: the end user is running the old version of the application, but she tries to install the new version at the same time. As we use major upgrade, the old version will be uninstalled first. So in this case, if the old version is running, we can't install the new version properly. I knew util:CloseApplication. So I tried that. But in our application, there is a requirement close application will just minimize the GUI to system tray just like Yahoo Messenger. I'm not sure if util:CloseApplication does send WM_CLOSE message to our application. But even if it does, our application will just minimize itself to system tray but not close itself. We already tested it. The application didn't shut down. So we can't use this util:CloseApplication. Then I tried another solution: http://n2.nabble.com/Custom-action-sequencing-problem-td709311.html#a709311 Well, it partly worked. If we keep the old version running, then the process is killed when installing the new version. However, just a few seconds later, the installation failed because of Error code 2753. I realized the old version was uninstalled, the new version wasn't installed. Also, I was thinking killing a process directly might not be a good thing. So I kept searching other solutions. Then I found someone said FilesInUse. I think this solution even works for us. So I added this line: UI DialogRef Id=FilesInUse / ... /UI Now we have new problem Error code 2753. I tried two cases: Case 1: I kept the old version running, and I installed the new version. During installation, the FilesInUse dialog did show up - I was very happy. Then I exited the old version. The installation kept going.. just a few seconds, it failed. I noticed the old version was uninstalled, but the new version wasn't installed. Here is the log: MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2753 2: MainApp MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2205 2: 3: Error MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2753 DEBUG: Error 2753: The File 'MainApp' is not marked for installation. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2753. The arguments are: MainApp, , MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2205 2: 3: Error MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (s) (48:4C) [10:15:44:245]: Product: BigAppleProduct -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2753. The arguments are: MainApp, , The log says error, but what the error means? What caused this error? The log didn't say. Case 2: do a fresh installation. There is no FilesInUse dialog showing up, of course. But the install still failed - Error 2753. This doesn't make any sense. It seems the problem is this new added line DialogRef Id=FilesInUse /. By adding this line, the error 2753 is introduced. Why is that? So how can I add this FilesInUse support in WiX 3? Where I did wrong here? Many many thanks. /Brian __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to add FilesInUse support
Let me correct something a bit: If not add DialogRef Id=FilesInUse / line, the installation is okay but it won't detect and show FilesInUse dialog. If add DialogRef Id=FilesInUse / line in code, the installation is okay if this is a fresh intallation(fresh means no previous version installed). If add DialogRef Id=FilesInUse / line in code, and there is the old version application running, then the installation of the new version will detect and show the FilesInUse dialog which is good. But later on the installation of the new version will be failed because of an Error called 2753. Why this happens? How to resolve it? Thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Friday, October 2, 2009 11:17:01 AM Subject: [WiX-users] How to add FilesInUse support We use WiX 3.0. We have a problem: the end user is running the old version of the application, but she tries to install the new version at the same time. As we use major upgrade, the old version will be uninstalled first. So in this case, if the old version is running, we can't install the new version properly. I knew util:CloseApplication. So I tried that. But in our application, there is a requirement close application will just minimize the GUI to system tray just like Yahoo Messenger. I'm not sure if util:CloseApplication does send WM_CLOSE message to our application. But even if it does, our application will just minimize itself to system tray but not close itself. We already tested it. The application didn't shut down. So we can't use this util:CloseApplication. Then I tried another solution: http://n2.nabble.com/Custom-action-sequencing-problem-td709311.html#a709311 Well, it partly worked. If we keep the old version running, then the process is killed when installing the new version. However, just a few seconds later, the installation failed because of Error code 2753. I realized the old version was uninstalled, the new version wasn't installed. Also, I was thinking killing a process directly might not be a good thing. So I kept searching other solutions. Then I found someone said FilesInUse. I think this solution even works for us. So I added this line: UI DialogRef Id=FilesInUse / ... /UI Now we have new problem Error code 2753. I tried two cases: Case 1: I kept the old version running, and I installed the new version. During installation, the FilesInUse dialog did show up - I was very happy. Then I exited the old version. The installation kept going.. just a few seconds, it failed. I noticed the old version was uninstalled, but the new version wasn't installed. Here is the log: MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2753 2: MainApp MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2205 2: 3: Error MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 2753 DEBUG: Error 2753: The File 'MainApp' is not marked for installation. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2753. The arguments are: MainApp, , MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2205 2: 3: Error MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI (s) (48:4C) [10:15:44:245]: Product: BigAppleProduct -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2753. The arguments are: MainApp, , The log says error, but what the error means? What caused this error? The log didn't say. Case 2: do a fresh installation. There is no FilesInUse dialog showing up, of course. But the install still failed - Error 2753. This doesn't make any sense. It seems the problem is this new added line DialogRef Id=FilesInUse /. By adding this line, the error 2753 is introduced. Why is that? So how can I add this FilesInUse support in WiX 3? Where I did wrong here? Many many thanks. /Brian __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users __ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http
Re: [WiX-users] How to add FilesInUse support
Hi Phil, Thanks for you reply. It's good to know that 2753 is nothing directly related to FilesInUse. For It's typically caused by running a custom action referring to a program that is not going to be installed. So it looks like you're asking to run MainApp but the one in your setup isn't being installed. - It's true. We do have a custom action like this(Does this code look okay?): CustomAction Id=ExecBootloader_Cmd FileKey=MainApp ExeCommand=-bootload Execute=deferred Return=ignore HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=ExecBootloader_Cmd Before=InstallFinalize / /InstallExecuteSequence As long as the old version wasn't running, the major upgrade worked fine. I mean, there wasn't error, the old version was removed, and the new version was installed. The custom action run okay as well. But, if the old version was running, we did see something different: we see the FilesInUse dialog, we shutdown the old version manually, so far so good, we kept it going.. then it failed. I noticed the application folder under Program Files was not even created. Netherless to say, anything new version wasn't installed. So when the custom action was triggered, the program can't be found, then error. So in here, it seems to me that the only difference is whether the old version is running and further FilesInUse. So for This can because there's a component or feature state that means it's not being installed, or yours isn't being installed because there's already one on the system with a higher version. - I doubt if it's about the version higher/lower. Because if this is true, then we couldn't explain why the new version was installed and run okay while the old version wasn't running. It's suppposed to fail even the old version wasn't running, right? Again, the only difference is the old version running. If not running, no FilesInUse showing up, things are okay. If running, the FilesInUse part behave correctly but nothing will be installed. So I guess this is about FilesInUse. But, really, I don't know the reason and the solution. By the way, we use WiX version 3.0.4805.0. If you have any idea, please let me know. Thanks a lot. /Brian From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Friday, October 2, 2009 1:57:16 PM Subject: Re: [WiX-users] How to add FilesInUse support 2753 is nothing directly related to FilesInUse - look up the Windows SDK Windows Installer errors for this kind of thing. It's typically caused by running a custom action referring to a program that is not going to be installed. So it looks like you're asking to run MainApp but the one in your setup isn't being installed. This can because there's a component or feature state that means it's not being installed, or yours isn't being installed because there's already one on the system with a higher version. Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Friday, October 02, 2009 12:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to add FilesInUse support Let me correct something a bit: If not add DialogRef Id=FilesInUse / line, the installation is okay but it won't detect and show FilesInUse dialog. If add DialogRef Id=FilesInUse / line in code, the installation is okay if this is a fresh intallation(fresh means no previous version installed). If add DialogRef Id=FilesInUse / line in code, and there is the old version application running, then the installation of the new version will detect and show the FilesInUse dialog which is good. But later on the installation of the new version will be failed because of an Error called 2753. Why this happens? How to resolve it? Thanks. From: little.forest little.for...@ymail.com To: wix-users@lists.sourceforge.net Sent: Friday, October 2, 2009 11:17:01 AM Subject: [WiX-users] How to add FilesInUse support We use WiX 3.0. We have a problem: the end user is running the old version of the application, but she tries to install the new version at the same time. As we use major upgrade, the old version will be uninstalled first. So in this case, if the old version is running, we can't install the new version properly. I knew util:CloseApplication. So I tried that. But in our application, there is a requirement close application will just minimize the GUI to system tray just like Yahoo Messenger. I'm not sure if util:CloseApplication does send WM_CLOSE message to our application. But even if it does, our application will just minimize itself to system tray but not close itself. We already tested it. The application didn't shut down. So we can't use this util:CloseApplication. Then I tried another solution: http://n2.nabble.com/Custom-action-sequencing-problem
Re: [WiX-users] How to add FilesInUse support
Just double checked: The new version of the installer is higher than the old installer; the version of the new main application is higher than the old version of the main application. So I think this is not about the version, but I don't know. Also, can you tell me if my code for FilesInUse correct? I found this: http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html There are quite a few other DialogRef listed: DialogRef Id=ErrorDlg / DialogRef Id=FatalError / DialogRef Id=FilesInUse / DialogRef Id=MsiRMFilesInUse / DialogRef Id=PrepareDlg / DialogRef Id=ProgressDlg / DialogRef Id=ResumeDlg / DialogRef Id=UserExit / Should I do the same thing? Anyways, if you know anything about FilesInUse, please let me know. Thanks. /Brian From: little.forest little.for...@ymail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Friday, October 2, 2009 2:42:41 PM Subject: Re: [WiX-users] How to add FilesInUse support Hi Phil, Thanks for you reply. It's good to know that 2753 is nothing directly related to FilesInUse. For It's typically caused by running a custom action referring to a program that is not going to be installed. So it looks like you're asking to run MainApp but the one in your setup isn't being installed. - It's true. We do have a custom action like this(Does this code look okay?): CustomAction Id=ExecBootloader_Cmd FileKey=MainApp ExeCommand=-bootload Execute=deferred Return=ignore HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=ExecBootloader_Cmd Before=InstallFinalize / /InstallExecuteSequence As long as the old version wasn't running, the major upgrade worked fine. I mean, there wasn't error, the old version was removed, and the new version was installed. The custom action run okay as well. But, if the old version was running, we did see something different: we see the FilesInUse dialog, we shutdown the old version manually, so far so good, we kept it going.. then it failed. I noticed the application folder under Program Files was not even created. Netherless to say, anything new version wasn't installed. So when the custom action was triggered, the program can't be found, then error. So in here, it seems to me that the only difference is whether the old version is running and further FilesInUse. So for This can because there's a component or feature state that means it's not being installed, or yours isn't being installed because there's already one on the system with a higher version. - I doubt if it's about the version higher/lower. Because if this is true, then we couldn't explain why the new version was installed and run okay while the old version wasn't running. It's suppposed to fail even the old version wasn't running, right? Again, the only difference is the old version running. If not running, no FilesInUse showing up, things are okay. If running, the FilesInUse part behave correctly but nothing will be installed. So I guess this is about FilesInUse. But, really, I don't know the reason and the solution. By the way, we use WiX version 3.0.4805.0. If you have any idea, please let me know. Thanks a lot. /Brian From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Friday, October 2, 2009 1:57:16 PM Subject: Re: [WiX-users] How to add FilesInUse support 2753 is nothing directly related to FilesInUse - look up the Windows SDK Windows Installer errors for this kind of thing. It's typically caused by running a custom action referring to a program that is not going to be installed. So it looks like you're asking to run MainApp but the one in your setup isn't being installed. This can because there's a component or feature state that means it's not being installed, or yours isn't being installed because there's already one on the system with a higher version. Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Friday, October 02, 2009 12:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to add FilesInUse support Let me correct something a bit: If not add DialogRef Id=FilesInUse / line, the installation is okay but it won't detect and show FilesInUse dialog. If add DialogRef Id=FilesInUse / line in code, the installation is okay if this is a fresh intallation(fresh means no previous version installed). If add DialogRef Id=FilesInUse / line in code, and there is the old version application running, then the installation of the new version will detect and show the FilesInUse dialog which is good. But later on the installation of the new version will be failed because of an Error called 2753. Why this happens? How to resolve it? Thanks. From: little.forest
Re: [WiX-users] How to add FilesInUse support
Thanks Phil! I really appreciate your reply and your time. If MainApp running and FilesInUse does not shut it down, then it cannot be replaced on the system, so it can't be run. - Correct. This is why we need to put this FilesInUse in. Here are what I experienced: - the old version running - start running the new version installer - a few seconds, the FilesInUse dialog showed up - I manually exit the old version of application - the new version installation process kept going.. a few seconds, the build failed Error 2753 - go to the Program Files folder, the application folder wasn't even created. Is it doing something that requires it to be a custom action actually being installed onto the system? I'm thinking it can be in the Binary table, depending on why it's being run. - Our application is a .NET 3.5 WPF based application. The application is written in C#. There is a perform issue. Every time when the application startup, it'll take a fair mount of time to start. So the development team came up with an idea. The idea is, right after the installation and before the end user launching the application, start the bootloader by using the main application with a command line argument(something like mainapp.exe -bootload). Note: the main application name is mainapp.exe. If we real run the application, the same mainapp.exe will be executed. What this -bootload does is that it will start some services, load some DLL files etc. I'm not sure whether this design is good or not. But it does work fine. When the end user launch the application, she will feel the application is fast - because services and DLLs already loaded. So we need this custom action to start this bootloader in installer. Actually, you know, this bootloader is the same as the main application, but just with an argument. Will this cause problem? But why there is no any files installed? The application folder not even created? I did schedule this custom action before InstallFinalize which is almost the end of the installation. I use custom action type 18 because the executable(actually it's the main application) is installed with the application, and I need to set the command line argument. Is this the problem? So one thing worth noticing, if there is no old version running, everything is fine. I'm really puzzled. Thanks again, Phil. /Brian From: Wilson, Phil phil.wil...@wonderware.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Friday, October 2, 2009 3:07:36 PM Subject: Re: [WiX-users] How to add FilesInUse support If MainApp running and FilesInUse does not shut it down, then it cannot be replaced on the system, so it can't be run. Is it doing something that requires it to be a custom action actually being installed onto the system? I'm thinking it can be in the Binary table, depending on why it's being run. Phil Wilson -Original Message- From: little.forest [mailto:little.for...@ymail.com] Sent: Friday, October 02, 2009 2:43 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to add FilesInUse support Hi Phil, Thanks for you reply. It's good to know that 2753 is nothing directly related to FilesInUse. For It's typically caused by running a custom action referring to a program that is not going to be installed. So it looks like you're asking to run MainApp but the one in your setup isn't being installed. - It's true. We do have a custom action like this(Does this code look okay?): CustomAction Id=ExecBootloader_Cmd FileKey=MainApp ExeCommand=-bootload Execute=deferred Return=ignore HideTarget=no Impersonate=no / InstallExecuteSequence Custom Action=ExecBootloader_Cmd Before=InstallFinalize / /InstallExecuteSequence As long as the old version wasn't running, the major upgrade worked fine. I mean, there wasn't error, the old version was removed, and the new version was installed. The custom action run okay as well. But, if the old version was running, we did see something different: we see the FilesInUse dialog, we shutdown the old version manually, so far so good, we kept it going.. then it failed. I noticed the application folder under Program Files was not even created. Netherless to say, anything new version wasn't installed. So when the custom action was triggered, the program can't be found, then error. So in here, it seems to me that the only difference is whether the old version is running and further FilesInUse. So for This can because there's a component or feature state that means it's not being installed, or yours isn't being installed because there's already one on the system with a higher version. - I doubt if it's about the version higher/lower. Because if this is true, then we couldn't explain why the new version was installed and run okay while the old version wasn't running. It's suppposed to fail even the old version wasn't
