Re: [WiX-users] Problems with CustomAction and major upgrade solved!
On Wed, May 04, 2011 at 12:58:09PM -0400, Chris Lord wrote: Chaining installers is a general no-no and Microsoft recommend you don't do it. Second, trying to install software in the Cost Finalise stage is also not a good idea. Installing something using a custom action makes it very difficult to roll back should the installation fail or be cancelled and it makes uninstalling your application difficult if not impossible. Your installer should allow a clean install and also a clean removal of you application (including DirectX if your applicaiton installs it) and given the design you are describing, that would be difficult to achieve. If you need to install a second application, the recommended method is to use a bootstrapper such as dotNetInstaller or WiX's own Burn facility. Its likely to cause you a lot less headaches in the long run. Chris Thanks for this advice. I agree and hope to adopt Burn once WiX 3.6 is finalized. For now I was following the advice given at http://wix.sourceforge.net/manual-wix3/install_directx9.htm. Do you think it would be worth adding a note about the inadvisability of installer chaining to that page? As for the solution: the logs produced (with the /l*v option to msiexec) indicated that the sequence of events was happening as follows: 1. Start of RemoveExistingProducts. This fires up the previous versions' installer and tells it to remove itself. 2. Skip InstallDirectX action because condition fails. Good. 3. Properties for the removal are logged, on lines starting with 'Property(N)'. The 'REMOVE' and 'Installed' properties are present. 4. End of RemoveExistingProducts. 5. Start of InstallDirectX. This is where I expected the 'NOT REMOVE' condition to prevent the installer from running, but it doesn't because the 'REMOVE' property is missing, as revealed below. 6. Properties for the failed install are logged. Lines start with 'Property(S)' for the execute sequence, and 'Property(C)' are for the UI sequence. The 'PREVIOUSFOUND' property is present. Setting the condition for the InstallDirectX action to 'NOT INSTALLED AND NOT PREVIOUSFOUND' therefore prevents the action from being running during a Major Upgrade. -- Sam Morris Red Redemption Please consider the fate of the world before printing this email! -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems with CustomAction and major upgrade solved!
Hi Sam, One thing to noteThe manual page states the custom action for DirectX runs after InstallFinalize which is right at the end of an installation. You have yours running a lot earlier than that. I don't know the consequences of moving it but you might try just doing as the manual states and see what happens. As far as the manual page is concerned, it seems to me to be advocating chaining which is a deprecated feature of Windows Installer and something Microsoft advise against doing. Given that's the case, is there something special about DirectX that means it can be installed that way or does indeed the page need updating in some way? Chris On 05/06/2011 08:23 AM, Sam Morris wrote: On Wed, May 04, 2011 at 12:58:09PM -0400, Chris Lord wrote: Chaining installers is a general no-no and Microsoft recommend you don't do it. Second, trying to install software in the Cost Finalise stage is also not a good idea. Installing something using a custom action makes it very difficult to roll back should the installation fail or be cancelled and it makes uninstalling your application difficult if not impossible. Your installer should allow a clean install and also a clean removal of you application (including DirectX if your applicaiton installs it) and given the design you are describing, that would be difficult to achieve. If you need to install a second application, the recommended method is to use a bootstrapper such as dotNetInstaller or WiX's own Burn facility. Its likely to cause you a lot less headaches in the long run. Chris Thanks for this advice. I agree and hope to adopt Burn once WiX 3.6 is finalized. For now I was following the advice given at http://wix.sourceforge.net/manual-wix3/install_directx9.htm. Do you think it would be worth adding a note about the inadvisability of installer chaining to that page? As for the solution: the logs produced (with the /l*v option to msiexec) indicated that the sequence of events was happening as follows: 1. Start of RemoveExistingProducts. This fires up the previous versions' installer and tells it to remove itself. 2. Skip InstallDirectX action because condition fails. Good. 3. Properties for the removal are logged, on lines starting with 'Property(N)'. The 'REMOVE' and 'Installed' properties are present. 4. End of RemoveExistingProducts. 5. Start of InstallDirectX. This is where I expected the 'NOT REMOVE' condition to prevent the installer from running, but it doesn't because the 'REMOVE' property is missing, as revealed below. 6. Properties for the failed install are logged. Lines start with 'Property(S)' for the execute sequence, and 'Property(C)' are for the UI sequence. The 'PREVIOUSFOUND' property is present. Setting the condition for the InstallDirectX action to 'NOT INSTALLED AND NOT PREVIOUSFOUND' therefore prevents the action from being running during a Major Upgrade. -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems with CustomAction and major upgrade solved!
On Fri, May 06, 2011 at 10:13:19AM -0400, Chris Lord wrote: Hi Sam, One thing to noteThe manual page states the custom action for DirectX runs after InstallFinalize which is right at the end of an installation. You have yours running a lot earlier than that. I don't know the consequences of moving it but you might try just doing as the manual states and see what happens. I actually schedule the action with before=InstallFinalize, as the web page suggests. I only mentioned CostFinalize in my original message because that was the action under which the messages about the component versions being the same was logged--it was a red herring. :) As far as the manual page is concerned, it seems to me to be advocating chaining which is a deprecated feature of Windows Installer and something Microsoft advise against doing. Given that's the case, is there something special about DirectX that means it can be installed that way or does indeed the page need updating in some way? This is probably a case of one part of Microsoft talking to the other. Installing DirectX has always been a bit, shall we say, special (depending on who you ask--I doubt sysadmins would be as polite). Microsoft's current recommendation can be found at http://msdn.microsoft.com/en-us/library/ee416805(v=vs.85).aspx. Basically you are supposed to always run dxsetup.exe /silent as part of your game's installation process, and you shouldn't allow the end user to opt out. There isn't even any way to uninstall DirectX--installation is permanent. That's why I am not too bothered about having another CustomAction that removes it when the product is uninstalled. Chris Regards, -- Sam Morris Red Redemption Please consider the fate of the world before printing this email! -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
