[WiX-users] Advice Needed / Package Custom Config File
Is it possible to use Wix to programmatically create an MSI Installer using a background process and an existing file structure? I would like to embed a customized configuration file within their downloadable installation package. I have never used Wix so any links to code or samples, demonstrating this ability, would be greatly appreciated. Thank you, in advance. - G. Deward -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Advice Needed / Package Custom Config File
If your MSI packages are always the same apart from that single configuration file, one way to do it would be to exclude file from the MSI. Then create a single, static MSI and let the application download the config file at runtime and configure itself, if it hasn't already done so. This would be particularly advisable if your config could change during the installed lifetime of the MSI, but less necessary if it never changes. It would greatly simplify building and maintenance of the MSI and allow user changes to be made to the config. MSI is much easier to manage when installing unchanging resources and it would be a lot simpler for you if there is only one MSI for all users. Whether this is a reasonable solution depends on the constraints of the target environments. If this doesn't help, perhaps you could elaborate on that aspect. -Original Message- From: Greg Deward [mailto:greg.dew...@gmail.com] Sent: 29 January 2013 12:08 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Advice Needed / Package Custom Config File Is it possible to use Wix to programmatically create an MSI Installer using a background process and an existing file structure? I would like to embed a customized configuration file within their downloadable installation package. I have never used Wix so any links to code or samples, demonstrating this ability, would be greatly appreciated. Thank you, in advance. - G. Deward - - Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Advice Needed / Package Custom Config File
Unfortunately, based on our current requirements, we must not prompt the user in any way nor may we require them to download a second file. Our client has requested that certain customer-specific variables be known by the application during install. The application must supply these variables to the servers when making any web service or restful call to the back end. This is why generating the MSI is so necessary. I hope this helps. Thanks for taking the time to reply. - Greg On Jan 29, 2013, at 7:25 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: If your MSI packages are always the same apart from that single configuration file, one way to do it would be to exclude file from the MSI. Then create a single, static MSI and let the application download the config file at runtime and configure itself, if it hasn't already done so. This would be particularly advisable if your config could change during the installed lifetime of the MSI, but less necessary if it never changes. It would greatly simplify building and maintenance of the MSI and allow user changes to be made to the config. MSI is much easier to manage when installing unchanging resources and it would be a lot simpler for you if there is only one MSI for all users. Whether this is a reasonable solution depends on the constraints of the target environments. If this doesn't help, perhaps you could elaborate on that aspect. -Original Message- From: Greg Deward [mailto:greg.dew...@gmail.com] Sent: 29 January 2013 12:08 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Advice Needed / Package Custom Config File Is it possible to use Wix to programmatically create an MSI Installer using a background process and an existing file structure? I would like to embed a customized configuration file within their downloadable installation package. I have never used Wix so any links to code or samples, demonstrating this ability, would be greatly appreciated. Thank you, in advance. - G. Deward - - Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Advice Needed / Package Custom Config File
There are other ways you could do it but if you've been told how to implement the requirement too, there's not much point going into it. To answer your question... Creating a process to make a Wix installer automatically is just the same as making any automated build. If you use Votive (Wix Visual Studio integration) to develop the installer, you will get a .wixproj which is an MSBuild project file and a solution file. You can either use the solution or project file and call devenv to compile it or you can call MSBuild directly. Your Wix source doesn't need to change - you'll just need to point your Component that contains the configuration file at the right file path using FileSource attribute of the File element. This can be hard coded, relative to some base path set in the light (link) stage, be an absolute path or be a pre-processor variable. See the wix help under How To: Specify source files. If you use a hardcoded path, you'll need to add a pre-build step, or add a task into the wixproj file to move the configuration file to the right location based on a property that you pass to msbuild. Alternately, you could pass the location of the config file at build time. It depends on how youre creating the customer specific file. Your product code should be a hard coded guid rather than * so that you know what you released to the customer and can reproduce it or make upgrades, assuming you can track the config files somehow. Or just store a copy of each MSI produced. The Wix help has sections on creating builds that will help so do have a look in there. -Original Message- From: Greg Deward [mailto:greg.dew...@gmail.com] Sent: 29 January 2013 12:44 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Advice Needed / Package Custom Config File Unfortunately, based on our current requirements, we must not prompt the user in any way nor may we require them to download a second file. Our client has requested that certain customer-specific variables be known by the application during install. The application must supply these variables to the servers when making any web service or restful call to the back end. This is why generating the MSI is so necessary. I hope this helps. Thanks for taking the time to reply. - Greg On Jan 29, 2013, at 7:25 AM, Peter Shirtcliffe pshirtcli...@sdl.com wrote: If your MSI packages are always the same apart from that single configuration file, one way to do it would be to exclude file from the MSI. Then create a single, static MSI and let the application download the config file at runtime and configure itself, if it hasn't already done so. This would be particularly advisable if your config could change during the installed lifetime of the MSI, but less necessary if it never changes. It would greatly simplify building and maintenance of the MSI and allow user changes to be made to the config. MSI is much easier to manage when installing unchanging resources and it would be a lot simpler for you if there is only one MSI for all users. Whether this is a reasonable solution depends on the constraints of the target environments. If this doesn't help, perhaps you could elaborate on that aspect. -Original Message- From: Greg Deward [mailto:greg.dew...@gmail.com] Sent: 29 January 2013 12:08 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Advice Needed / Package Custom Config File Is it possible to use Wix to programmatically create an MSI Installer using a background process and an existing file structure? I would like to embed a customized configuration file within their downloadable installation package. I have never used Wix so any links to code or samples, demonstrating this ability, would be greatly appreciated. Thank you, in advance. - G. Deward -- --- - Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
There appear to be 2 distinct problems here: 1) MSI's UI is not redisplayed on subsequent bootstrapper execution. 2) Install Conditions are not behaving as I expect. I've discovered that the uninstall is happening because I have two msi packages, one for 64-bit, and another for 32-bit. These msi's actually share the same wxs files, but have pre-processors variables to drop stuff in the correct locations depending upon the bit level of the machine. I have Install conditions on MSIPackage as such: !-- 32-bit -- MsiPackage Name=MSI\Our Product_x86.msi SourceFile=$(var.PkgLocation)Our Product_x86.msi InstallCondition=NOT VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage !-- 64-bit -- MsiPackage Name=MSI\Our Product_x64.msi SourceFile=$(var.PkgLocation)Our Product_x64.msi InstallCondition=VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage What seems to happen is: 1) On first bootstrapper run, the install conditions are evaluated properly on my x64 machine and only the 64-bit msi is executed. 2) On the second bootstrapper run, for some reason the 32-bit msi is executed with an uninstall action, which actually uninstalls the product even though it had been installed via the x64 msi, since they share product ids and upgrade codes. So the driving questions are: 1) Why is the x86 msi ignoring the install condition on the second run of the bootstrapper? 2) How do I get the x64 msi executed and have the msi's UI displayed as if I had launched the msi itself from the command line? Thanks! Karl On Tue, Jan 29, 2013 at 9:00 AM, Karl Werner karl.wer...@gmail.com wrote: Currently we have a Wix Bundle that provides minimal interaction through a custom .Net UI. We don't have the Bundle name set so the bootstrapper won't get registered in ARP (by design). It then chains some pre-rquisites and our product. Our product is an MsiPackage, something like this: MsiPackage Name=MSI\Our Product.msi SourceFile=$(var.PkgLocation)Our Product.msi DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage This all works great to install the product from the first launch of the bootstrapper exe. The MSI's UI gets displayed as desired, and the MSI shows up in ARP and not the bootstrapper. All good. However, when the bootstrapper exe is launched a second time, it silently uninstalls our product. It looks like the Plan generates an uninstall action when executing the MSI. The desired behavior is to redisplay the MSI's UI, which will then detect that the product is installed and give the users the options to Repair, Reinstall, etc. How can I do this? Thanks! Karl -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
My guess would be because you are sharing UpgradeCode. When burn runs a second time, the 32bit MsiPackage is going to detect based on upgrade code. Because your InstallCondition evaluates to false, it schedules the removal of it. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 9:32 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time There appear to be 2 distinct problems here: 1) MSI's UI is not redisplayed on subsequent bootstrapper execution. 2) Install Conditions are not behaving as I expect. I've discovered that the uninstall is happening because I have two msi packages, one for 64-bit, and another for 32-bit. These msi's actually share the same wxs files, but have pre-processors variables to drop stuff in the correct locations depending upon the bit level of the machine. I have Install conditions on MSIPackage as such: !-- 32-bit -- MsiPackage Name=MSI\Our Product_x86.msi SourceFile=$(var.PkgLocation)Our Product_x86.msi InstallCondition=NOT VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage !-- 64-bit -- MsiPackage Name=MSI\Our Product_x64.msi SourceFile=$(var.PkgLocation)Our Product_x64.msi InstallCondition=VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage What seems to happen is: 1) On first bootstrapper run, the install conditions are evaluated properly on my x64 machine and only the 64-bit msi is executed. 2) On the second bootstrapper run, for some reason the 32-bit msi is executed with an uninstall action, which actually uninstalls the product even though it had been installed via the x64 msi, since they share product ids and upgrade codes. So the driving questions are: 1) Why is the x86 msi ignoring the install condition on the second run of the bootstrapper? 2) How do I get the x64 msi executed and have the msi's UI displayed as if I had launched the msi itself from the command line? Thanks! Karl On Tue, Jan 29, 2013 at 9:00 AM, Karl Werner karl.wer...@gmail.com wrote: Currently we have a Wix Bundle that provides minimal interaction through a custom .Net UI. We don't have the Bundle name set so the bootstrapper won't get registered in ARP (by design). It then chains some pre-rquisites and our product. Our product is an MsiPackage, something like this: MsiPackage Name=MSI\Our Product.msi SourceFile=$(var.PkgLocation)Our Product.msi DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage This all works great to install the product from the first launch of the bootstrapper exe. The MSI's UI gets displayed as desired, and the MSI shows up in ARP and not the bootstrapper. All good. However, when the bootstrapper exe is launched a second time, it silently uninstalls our product. It looks like the Plan generates an uninstall action when executing the MSI. The desired behavior is to redisplay the MSI's UI, which will then detect that the product is installed and give the users the options to Repair, Reinstall, etc. How can I do this? Thanks! Karl -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
Ah, that makes sense and may be what is causing the 32-bit msi to be executed with uninstall. I'll look into how to fix that. Any ideas? It does not however explain why the MSI's UI is never displayed . . . Even if I take the InstallCondition out along with the second MsiPackage, I still don't get the UI on the second run of the bootstrapper. Thanks! Karl On Tue, Jan 29, 2013 at 10:05 AM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: My guess would be because you are sharing UpgradeCode. When burn runs a second time, the 32bit MsiPackage is going to detect based on upgrade code. Because your InstallCondition evaluates to false, it schedules the removal of it. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 9:32 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time There appear to be 2 distinct problems here: 1) MSI's UI is not redisplayed on subsequent bootstrapper execution. 2) Install Conditions are not behaving as I expect. I've discovered that the uninstall is happening because I have two msi packages, one for 64-bit, and another for 32-bit. These msi's actually share the same wxs files, but have pre-processors variables to drop stuff in the correct locations depending upon the bit level of the machine. I have Install conditions on MSIPackage as such: !-- 32-bit -- MsiPackage Name=MSI\Our Product_x86.msi SourceFile=$(var.PkgLocation)Our Product_x86.msi InstallCondition=NOT VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage !-- 64-bit -- MsiPackage Name=MSI\Our Product_x64.msi SourceFile=$(var.PkgLocation)Our Product_x64.msi InstallCondition=VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage What seems to happen is: 1) On first bootstrapper run, the install conditions are evaluated properly on my x64 machine and only the 64-bit msi is executed. 2) On the second bootstrapper run, for some reason the 32-bit msi is executed with an uninstall action, which actually uninstalls the product even though it had been installed via the x64 msi, since they share product ids and upgrade codes. So the driving questions are: 1) Why is the x86 msi ignoring the install condition on the second run of the bootstrapper? 2) How do I get the x64 msi executed and have the msi's UI displayed as if I had launched the msi itself from the command line? Thanks! Karl On Tue, Jan 29, 2013 at 9:00 AM, Karl Werner karl.wer...@gmail.com wrote: Currently we have a Wix Bundle that provides minimal interaction through a custom .Net UI. We don't have the Bundle name set so the bootstrapper won't get registered in ARP (by design). It then chains some pre-rquisites and our product. Our product is an MsiPackage, something like this: MsiPackage Name=MSI\Our Product.msi SourceFile=$(var.PkgLocation)Our Product.msi DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage This all works great to install the product from the first launch of the bootstrapper exe. The MSI's UI gets displayed as desired, and the MSI shows up in ARP and not the bootstrapper. All good. However, when the bootstrapper exe is launched a second time, it silently uninstalls our product. It looks like the Plan generates an uninstall action when executing the MSI. The desired behavior is to redisplay the MSI's UI, which will then detect that the product is installed and give the users the options to Repair, Reinstall, etc. How can I do this? Thanks! Karl -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at:
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
So I populated the UpgradeCode using a pre-processor variable and use a different code in the build properties for the x86 vs. x64 projects. This seems to fix the uninstall issue. Now back to how to re-display the MSI's UI on subsequent runs of the bootstrapper? Thanks! Karl On Tue, Jan 29, 2013 at 10:22 AM, Karl Werner karl.wer...@gmail.com wrote: Ah, that makes sense and may be what is causing the 32-bit msi to be executed with uninstall. I'll look into how to fix that. Any ideas? It does not however explain why the MSI's UI is never displayed . . . Even if I take the InstallCondition out along with the second MsiPackage, I still don't get the UI on the second run of the bootstrapper. Thanks! Karl On Tue, Jan 29, 2013 at 10:05 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: My guess would be because you are sharing UpgradeCode. When burn runs a second time, the 32bit MsiPackage is going to detect based on upgrade code. Because your InstallCondition evaluates to false, it schedules the removal of it. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 9:32 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time There appear to be 2 distinct problems here: 1) MSI's UI is not redisplayed on subsequent bootstrapper execution. 2) Install Conditions are not behaving as I expect. I've discovered that the uninstall is happening because I have two msi packages, one for 64-bit, and another for 32-bit. These msi's actually share the same wxs files, but have pre-processors variables to drop stuff in the correct locations depending upon the bit level of the machine. I have Install conditions on MSIPackage as such: !-- 32-bit -- MsiPackage Name=MSI\Our Product_x86.msi SourceFile=$(var.PkgLocation)Our Product_x86.msi InstallCondition=NOT VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage !-- 64-bit -- MsiPackage Name=MSI\Our Product_x64.msi SourceFile=$(var.PkgLocation)Our Product_x64.msi InstallCondition=VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage What seems to happen is: 1) On first bootstrapper run, the install conditions are evaluated properly on my x64 machine and only the 64-bit msi is executed. 2) On the second bootstrapper run, for some reason the 32-bit msi is executed with an uninstall action, which actually uninstalls the product even though it had been installed via the x64 msi, since they share product ids and upgrade codes. So the driving questions are: 1) Why is the x86 msi ignoring the install condition on the second run of the bootstrapper? 2) How do I get the x64 msi executed and have the msi's UI displayed as if I had launched the msi itself from the command line? Thanks! Karl On Tue, Jan 29, 2013 at 9:00 AM, Karl Werner karl.wer...@gmail.com wrote: Currently we have a Wix Bundle that provides minimal interaction through a custom .Net UI. We don't have the Bundle name set so the bootstrapper won't get registered in ARP (by design). It then chains some pre-rquisites and our product. Our product is an MsiPackage, something like this: MsiPackage Name=MSI\Our Product.msi SourceFile=$(var.PkgLocation)Our Product.msi DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage This all works great to install the product from the first launch of the bootstrapper exe. The MSI's UI gets displayed as desired, and the MSI shows up in ARP and not the bootstrapper. All good. However, when the bootstrapper exe is launched a second time, it silently uninstalls our product. It looks like the Plan generates an uninstall action when executing the MSI. The desired behavior is to redisplay the MSI's UI, which will then detect that the product is installed and give the users the options to Repair, Reinstall, etc. How can I do this? Thanks! Karl -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
While I'm still stuck on the core issue here of not being able to redisplay the UI from the bootstrapper, I thought I'd document another way around the ancillary uninstall issue: Add a ComponentSearch for a component that the msi's will install: util:ComponentSearch Guid=YOURGUID-9609-4907-83FB-234DA4753C9F Variable=ProductInstalled/ Then set the InstallConditions similar to this: MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR NOT VersionNT64 EnableFeatureSelection=yes Visible=yes/ MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller64.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR VersionNT64 EnableFeatureSelection=yes Visible=yes/ Karl On Tue, Jan 29, 2013 at 10:34 AM, Karl Werner karl.wer...@gmail.com wrote: So I populated the UpgradeCode using a pre-processor variable and use a different code in the build properties for the x86 vs. x64 projects. This seems to fix the uninstall issue. Now back to how to re-display the MSI's UI on subsequent runs of the bootstrapper? Thanks! Karl On Tue, Jan 29, 2013 at 10:22 AM, Karl Werner karl.wer...@gmail.comwrote: Ah, that makes sense and may be what is causing the 32-bit msi to be executed with uninstall. I'll look into how to fix that. Any ideas? It does not however explain why the MSI's UI is never displayed . . . Even if I take the InstallCondition out along with the second MsiPackage, I still don't get the UI on the second run of the bootstrapper. Thanks! Karl On Tue, Jan 29, 2013 at 10:05 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: My guess would be because you are sharing UpgradeCode. When burn runs a second time, the 32bit MsiPackage is going to detect based on upgrade code. Because your InstallCondition evaluates to false, it schedules the removal of it. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 9:32 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time There appear to be 2 distinct problems here: 1) MSI's UI is not redisplayed on subsequent bootstrapper execution. 2) Install Conditions are not behaving as I expect. I've discovered that the uninstall is happening because I have two msi packages, one for 64-bit, and another for 32-bit. These msi's actually share the same wxs files, but have pre-processors variables to drop stuff in the correct locations depending upon the bit level of the machine. I have Install conditions on MSIPackage as such: !-- 32-bit -- MsiPackage Name=MSI\Our Product_x86.msi SourceFile=$(var.PkgLocation)Our Product_x86.msi InstallCondition=NOT VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage !-- 64-bit -- MsiPackage Name=MSI\Our Product_x64.msi SourceFile=$(var.PkgLocation)Our Product_x64.msi InstallCondition=VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage What seems to happen is: 1) On first bootstrapper run, the install conditions are evaluated properly on my x64 machine and only the 64-bit msi is executed. 2) On the second bootstrapper run, for some reason the 32-bit msi is executed with an uninstall action, which actually uninstalls the product even though it had been installed via the x64 msi, since they share product ids and upgrade codes. So the driving questions are: 1) Why is the x86 msi ignoring the install condition on the second run of the bootstrapper? 2) How do I get the x64 msi executed and have the msi's UI displayed as if I had launched the msi itself from the command line? Thanks! Karl On Tue, Jan 29, 2013 at 9:00 AM, Karl Werner karl.wer...@gmail.com wrote: Currently we have a Wix Bundle that provides minimal interaction through a custom .Net UI. We don't have the Bundle name set so the bootstrapper won't get registered in ARP (by design). It then chains some pre-rquisites and our product. Our product is an MsiPackage, something like this: MsiPackage Name=MSI\Our Product.msi SourceFile=$(var.PkgLocation)Our Product.msi DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage This all works great to install the product from the first launch of the bootstrapper exe. The MSI's UI gets displayed as desired, and
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
But if the same component is used in both the 32 bit and 64 bit MSI, a repair or removal is going to find InstallCondition=true for both packages. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 11:12 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time While I'm still stuck on the core issue here of not being able to redisplay the UI from the bootstrapper, I thought I'd document another way around the ancillary uninstall issue: Add a ComponentSearch for a component that the msi's will install: util:ComponentSearch Guid=YOURGUID-9609-4907-83FB-234DA4753C9F Variable=ProductInstalled/ Then set the InstallConditions similar to this: MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR NOT VersionNT64 EnableFeatureSelection=yes Visible=yes/ MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller64.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR VersionNT64 EnableFeatureSelection=yes Visible=yes/ Karl On Tue, Jan 29, 2013 at 10:34 AM, Karl Werner karl.wer...@gmail.com wrote: So I populated the UpgradeCode using a pre-processor variable and use a different code in the build properties for the x86 vs. x64 projects. This seems to fix the uninstall issue. Now back to how to re-display the MSI's UI on subsequent runs of the bootstrapper? Thanks! Karl On Tue, Jan 29, 2013 at 10:22 AM, Karl Werner karl.wer...@gmail.comwrote: Ah, that makes sense and may be what is causing the 32-bit msi to be executed with uninstall. I'll look into how to fix that. Any ideas? It does not however explain why the MSI's UI is never displayed . . . Even if I take the InstallCondition out along with the second MsiPackage, I still don't get the UI on the second run of the bootstrapper. Thanks! Karl On Tue, Jan 29, 2013 at 10:05 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: My guess would be because you are sharing UpgradeCode. When burn runs a second time, the 32bit MsiPackage is going to detect based on upgrade code. Because your InstallCondition evaluates to false, it schedules the removal of it. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 9:32 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time There appear to be 2 distinct problems here: 1) MSI's UI is not redisplayed on subsequent bootstrapper execution. 2) Install Conditions are not behaving as I expect. I've discovered that the uninstall is happening because I have two msi packages, one for 64-bit, and another for 32-bit. These msi's actually share the same wxs files, but have pre-processors variables to drop stuff in the correct locations depending upon the bit level of the machine. I have Install conditions on MSIPackage as such: !-- 32-bit -- MsiPackage Name=MSI\Our Product_x86.msi SourceFile=$(var.PkgLocation)Our Product_x86.msi InstallCondition=NOT VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage !-- 64-bit -- MsiPackage Name=MSI\Our Product_x64.msi SourceFile=$(var.PkgLocation)Our Product_x64.msi InstallCondition=VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage What seems to happen is: 1) On first bootstrapper run, the install conditions are evaluated properly on my x64 machine and only the 64-bit msi is executed. 2) On the second bootstrapper run, for some reason the 32-bit msi is executed with an uninstall action, which actually uninstalls the product even though it had been installed via the x64 msi, since they share product ids and upgrade codes. So the driving questions are: 1) Why is the x86 msi ignoring the install condition on the second run of the bootstrapper? 2) How do I get the x64 msi executed and have the msi's UI displayed as if I had launched the msi itself from the command line? Thanks! Karl On Tue, Jan 29, 2013 at 9:00 AM, Karl Werner karl.wer...@gmail.com wrote: Currently we have a Wix Bundle that provides minimal interaction through a custom .Net UI. We don't have the Bundle name set so the bootstrapper won't get registered in ARP (by design). It then chains some pre-rquisites and our product. Our product is an MsiPackage, something
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
Since the bootstrapper isn't registering itself in ARP, that shouldn't matter, right? On Tue, Jan 29, 2013 at 11:24 AM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: But if the same component is used in both the 32 bit and 64 bit MSI, a repair or removal is going to find InstallCondition=true for both packages. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 11:12 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time While I'm still stuck on the core issue here of not being able to redisplay the UI from the bootstrapper, I thought I'd document another way around the ancillary uninstall issue: Add a ComponentSearch for a component that the msi's will install: util:ComponentSearch Guid=YOURGUID-9609-4907-83FB-234DA4753C9F Variable=ProductInstalled/ Then set the InstallConditions similar to this: MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR NOT VersionNT64 EnableFeatureSelection=yes Visible=yes/ MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller64.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR VersionNT64 EnableFeatureSelection=yes Visible=yes/ Karl On Tue, Jan 29, 2013 at 10:34 AM, Karl Werner karl.wer...@gmail.com wrote: So I populated the UpgradeCode using a pre-processor variable and use a different code in the build properties for the x86 vs. x64 projects. This seems to fix the uninstall issue. Now back to how to re-display the MSI's UI on subsequent runs of the bootstrapper? Thanks! Karl On Tue, Jan 29, 2013 at 10:22 AM, Karl Werner karl.wer...@gmail.com wrote: Ah, that makes sense and may be what is causing the 32-bit msi to be executed with uninstall. I'll look into how to fix that. Any ideas? It does not however explain why the MSI's UI is never displayed . . . Even if I take the InstallCondition out along with the second MsiPackage, I still don't get the UI on the second run of the bootstrapper. Thanks! Karl On Tue, Jan 29, 2013 at 10:05 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: My guess would be because you are sharing UpgradeCode. When burn runs a second time, the 32bit MsiPackage is going to detect based on upgrade code. Because your InstallCondition evaluates to false, it schedules the removal of it. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 9:32 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time There appear to be 2 distinct problems here: 1) MSI's UI is not redisplayed on subsequent bootstrapper execution. 2) Install Conditions are not behaving as I expect. I've discovered that the uninstall is happening because I have two msi packages, one for 64-bit, and another for 32-bit. These msi's actually share the same wxs files, but have pre-processors variables to drop stuff in the correct locations depending upon the bit level of the machine. I have Install conditions on MSIPackage as such: !-- 32-bit -- MsiPackage Name=MSI\Our Product_x86.msi SourceFile=$(var.PkgLocation)Our Product_x86.msi InstallCondition=NOT VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage !-- 64-bit -- MsiPackage Name=MSI\Our Product_x64.msi SourceFile=$(var.PkgLocation)Our Product_x64.msi InstallCondition=VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage What seems to happen is: 1) On first bootstrapper run, the install conditions are evaluated properly on my x64 machine and only the 64-bit msi is executed. 2) On the second bootstrapper run, for some reason the 32-bit msi is executed with an uninstall action, which actually uninstalls the product even though it had been installed via the x64 msi, since they share product ids and upgrade codes. So the driving questions are: 1) Why is the x86 msi ignoring the install condition on the second run of the bootstrapper? 2) How do I get the x64 msi executed and have the msi's UI displayed as if I had launched the msi itself from the command line? Thanks! Karl On Tue, Jan 29, 2013 at 9:00 AM, Karl Werner karl.wer...@gmail.com wrote: Currently we have a Wix
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
But if they run the downloaded bundle a second time it would, I believe. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 1:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time Since the bootstrapper isn't registering itself in ARP, that shouldn't matter, right? On Tue, Jan 29, 2013 at 11:24 AM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: But if the same component is used in both the 32 bit and 64 bit MSI, a repair or removal is going to find InstallCondition=true for both packages. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 11:12 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time While I'm still stuck on the core issue here of not being able to redisplay the UI from the bootstrapper, I thought I'd document another way around the ancillary uninstall issue: Add a ComponentSearch for a component that the msi's will install: util:ComponentSearch Guid=YOURGUID-9609-4907-83FB-234DA4753C9F Variable=ProductInstalled/ Then set the InstallConditions similar to this: MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR NOT VersionNT64 EnableFeatureSelection=yes Visible=yes/ MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller64.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR VersionNT64 EnableFeatureSelection=yes Visible=yes/ Karl On Tue, Jan 29, 2013 at 10:34 AM, Karl Werner karl.wer...@gmail.com wrote: So I populated the UpgradeCode using a pre-processor variable and use a different code in the build properties for the x86 vs. x64 projects. This seems to fix the uninstall issue. Now back to how to re-display the MSI's UI on subsequent runs of the bootstrapper? Thanks! Karl On Tue, Jan 29, 2013 at 10:22 AM, Karl Werner karl.wer...@gmail.com wrote: Ah, that makes sense and may be what is causing the 32-bit msi to be executed with uninstall. I'll look into how to fix that. Any ideas? It does not however explain why the MSI's UI is never displayed . . . Even if I take the InstallCondition out along with the second MsiPackage, I still don't get the UI on the second run of the bootstrapper. Thanks! Karl On Tue, Jan 29, 2013 at 10:05 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: My guess would be because you are sharing UpgradeCode. When burn runs a second time, the 32bit MsiPackage is going to detect based on upgrade code. Because your InstallCondition evaluates to false, it schedules the removal of it. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 9:32 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time There appear to be 2 distinct problems here: 1) MSI's UI is not redisplayed on subsequent bootstrapper execution. 2) Install Conditions are not behaving as I expect. I've discovered that the uninstall is happening because I have two msi packages, one for 64-bit, and another for 32-bit. These msi's actually share the same wxs files, but have pre-processors variables to drop stuff in the correct locations depending upon the bit level of the machine. I have Install conditions on MSIPackage as such: !-- 32-bit -- MsiPackage Name=MSI\Our Product_x86.msi SourceFile=$(var.PkgLocation)Our Product_x86.msi InstallCondition=NOT VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage !-- 64-bit -- MsiPackage Name=MSI\Our Product_x64.msi SourceFile=$(var.PkgLocation)Our Product_x64.msi InstallCondition=VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage What seems to happen is: 1) On first bootstrapper run, the install conditions are evaluated properly on my x64 machine and only the 64-bit msi is executed. 2) On the second bootstrapper run, for some reason the 32-bit msi is executed with an uninstall action, which actually uninstalls the product even though it had been installed via the x64 msi, since they share product ids and upgrade codes. So the driving questions are:
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
So if I use different upgrade codes, defined using pre-processor variables, then that should prevent the problem in all cases, I suppose. However, still stuck on the original problem - How can I get the MSI's UI invoked on the second run of the bootstrapper. On Tue, Jan 29, 2013 at 2:23 PM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: But if they run the downloaded bundle a second time it would, I believe. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 1:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time Since the bootstrapper isn't registering itself in ARP, that shouldn't matter, right? On Tue, Jan 29, 2013 at 11:24 AM, Hoover, Jacob jacob.hoo...@greenheck.comwrote: But if the same component is used in both the 32 bit and 64 bit MSI, a repair or removal is going to find InstallCondition=true for both packages. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 11:12 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time While I'm still stuck on the core issue here of not being able to redisplay the UI from the bootstrapper, I thought I'd document another way around the ancillary uninstall issue: Add a ComponentSearch for a component that the msi's will install: util:ComponentSearch Guid=YOURGUID-9609-4907-83FB-234DA4753C9F Variable=ProductInstalled/ Then set the InstallConditions similar to this: MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR NOT VersionNT64 EnableFeatureSelection=yes Visible=yes/ MsiPackage Name='msi\$(var.WixBootstrapperTestInstaller64.TargetFileName)' SourceFile=$(var.WixBootstrapperTestInstaller.TargetPath) DisplayInternalUI=yes InstallCondition=ProductInstalled OR VersionNT64 EnableFeatureSelection=yes Visible=yes/ Karl On Tue, Jan 29, 2013 at 10:34 AM, Karl Werner karl.wer...@gmail.com wrote: So I populated the UpgradeCode using a pre-processor variable and use a different code in the build properties for the x86 vs. x64 projects. This seems to fix the uninstall issue. Now back to how to re-display the MSI's UI on subsequent runs of the bootstrapper? Thanks! Karl On Tue, Jan 29, 2013 at 10:22 AM, Karl Werner karl.wer...@gmail.com wrote: Ah, that makes sense and may be what is causing the 32-bit msi to be executed with uninstall. I'll look into how to fix that. Any ideas? It does not however explain why the MSI's UI is never displayed . . . Even if I take the InstallCondition out along with the second MsiPackage, I still don't get the UI on the second run of the bootstrapper. Thanks! Karl On Tue, Jan 29, 2013 at 10:05 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: My guess would be because you are sharing UpgradeCode. When burn runs a second time, the 32bit MsiPackage is going to detect based on upgrade code. Because your InstallCondition evaluates to false, it schedules the removal of it. -Original Message- From: Karl Werner [mailto:karl.wer...@gmail.com] Sent: Tuesday, January 29, 2013 9:32 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time There appear to be 2 distinct problems here: 1) MSI's UI is not redisplayed on subsequent bootstrapper execution. 2) Install Conditions are not behaving as I expect. I've discovered that the uninstall is happening because I have two msi packages, one for 64-bit, and another for 32-bit. These msi's actually share the same wxs files, but have pre-processors variables to drop stuff in the correct locations depending upon the bit level of the machine. I have Install conditions on MSIPackage as such: !-- 32-bit -- MsiPackage Name=MSI\Our Product_x86.msi SourceFile=$(var.PkgLocation)Our Product_x86.msi InstallCondition=NOT VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage !-- 64-bit -- MsiPackage Name=MSI\Our Product_x64.msi SourceFile=$(var.PkgLocation)Our Product_x64.msi InstallCondition=VersionNT64 DisplayInternalUI=yes EnableFeatureSelection=yes Visible=yes MsiProperty Name=INSTALLLOCATION Value=[InstallFolder]Our Product / /MsiPackage
[WiX-users] ExePackage that requires .NET installed earlier in Bundle
I'm creating a Bundle that installs the .NET Framework 4 and then SQL Server Express as needed. The Chain element looks as follows: Chain PackageGroupRef Id=NetFx40Redist/ ExePackage InstallCommand=.. Id=SqlExpress2008x64 DetectCondition=(On x64 and needed) PerMachine=yes DownloadUrl=..url.. SourceFile=redist\SQLEXPR_x64_ENU.exe Name=redist\SQLEXPR_x64_ENU.exe Compressed=no/ ExePackage InstallCommand=... Id=SqlExpress2008 Name=redist\SQLEXPR_x86_ENU.exe Compressed=no DetectCondition=(On an x86 machine) PerMachine=yes DownloadUrl=..url.. SourceFile=redist\SQLEXPR_x86_ENU.exe/ /Chain If .Net Framework 4 is already installed, SQL Server installs fine. If .Net Framework 4 is not installed, the SQL Server Express install fails because it says the .Net Framework is not installed. In fact, it says it needs the exact same version as was just installed in the previous step. I don't know Burn very well so I'm wondering if the .Net Framework install needs to be committed in some way before it can be used by the Sql Server install. I tried putting a RollbackBoundary after the .Net install but it didn't seem to help. Any one have any suggestions? Thanks, Eric -- Eric Schultz, Developer Advocate, Outercurve Foundation http://www.outercurve.org eschu...@outercurve.org cell: 920-539-0404 skype: ericschultzwi @EricOutercurve -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Paying Job for Wix Guru
One of my partners was kind enough to post an Elance job to help entice someone to demonstrate to how tackle my earlier question with WIX. The direct link is... https://www.elance.com/j/dynamic-wix-installation-package/37325289 Anyone interested? -- G. Deward Begin forwarded message: Job Name: Dynamic WIX Installation Package Job Description: Help us understand how to use the WIX Installer to dynamically generate MSI packages. During the process you will need to replace values in config files before compiling the packaging the MSIs. Here is what we need... Create a command line application to dynamically generate three MSI installation packages using WIX while accepting a command line variable (called request_identifier) and inserting this value into a App.Config file before compiling. The end result will be one installer that calls either, or both, of the other MSI packages which both have a valid configuration file pre-configured with the supplied request_identifier value. To complete this project, you will be required to create and deliver: A. One .NET command line application with a tokenized App.Config file; B. One .NET Windows application with a tokenized config file; C. Visual Studio setup projects for each of the sample projects (A B) above; D. One installation program that allows the user to optionally install either or both of the sample projects (A B) above; E. A Word document or Camtasia video (with voice) explaining how the process application works,how to modify the number of sample applications being deployed, and how to modify text and images within the main installer. Please explain if you are interested in ADDITIONAL projects when submitting your proposal. This project is being used to help our team rapidly gain an understanding of the WIX environment while satisfying a few of our immediate needs. We would like to leverage a contractor moving forward for all installation packaging. Preference will be given to those who can deliver in the shortest amount of time. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Weird Repair happening...
I have installed my product and it works like a charm... I have modified my install to work with Repair since I have a lot of custom actions and 5 merge modules. When I run repair all is good EXCEPT all files are being installed in 1 folder I have 5 folders: C:\Program Files\MYCORP\MYCORP Services\Common C:\Program Files\MYCORP\MYCORP Services\Enterprise1Service C:\Program Files\MYCORP\MYCORP Services\Enterprise2Service C:\Program Files\MYCORP\MYCORP Services\Enterprise3Service C:\Program Files\MYCORP\MYCORP Services\Enterprise4Service It has changed the installation directory to the last folder instead of the 4 individual ones :( They all share common files except for 2 or 3 files (a config file and a dll) My merge modules are: Directory Id=ProgramFiles64Folder DiskId=1 Directory Id=INSTALLFOLDER Name=MYCORP DiskId=1 Directory Id=DIRECTORY_PATH_SERVICES Name=MYCORP Services DiskId=1 Merge Id=Enterprise1ServicesMM DiskId=1 SourceFile=$(var.SolutionDir)..\wixlibx64\MyCorpEnterprise1ServicesMergeModule.msm Language=1033/ Merge Id=Enterprise2ServicesMM DiskId=1 SourceFile=$(var.SolutionDir)..\wixlibx64\MyCorpEnterprise2ServicesMergeModule.msm Language=1033/ Merge Id=Enterprise3ServicesMM DiskId=1 SourceFile=$(var.SolutionDir)..\wixlibx64\MyCorpEnterprise3ServicesMergeModule.msm Language=1033/ Merge Id=Enterprise4ServicesMM DiskId=1 SourceFile=$(var.SolutionDir)..\wixlibx64\MyCorpEnterprise4ServicesMergeModule.msm Language=1033/ Merge Id=MyCorpServicesMergeModule DiskId=1 SourceFile=$(var.SolutionDir)..\wixlibx64\MyCorpServicesMergeModule.msm Language=1033/ Each merge module looks similar to this: Module Id=Enterprise4ServicesMM Language=1033 Version=1.0.0.0 Package Id=quot;lt;A GUID Manufacturer=MyCorp InstallerVersion=200 / Directory Id=TARGETDIR Name=SourceDir Directory Id=MergeRedirectFolder Directory Id=WixLibRedirectFolder Name=Enterprise4Service each merge module has a different WixLibRedirectFolder... All files are being installed to that particular WixLibRedirectFolder... The repair log file is: Command Line: ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 SERVER_INSTALL=0 REINSTALL=ALL REINSTALLMODE=cmuse REBOOT=ReallySuppress IGNOREDEPENDENCIES=ALL CURRENTDIRECTORY=C:\Windows\system32 CLIENTUILEVEL=3 MSICLIENTUSESEXTERNALUI=1 CLIENTPROCESSID=2312 PROPERTY CHANGE: Adding WixLibRedirectFolder.9EFC3F5B_3D47_4233_A162_371DEF5D8E92 property. Its value is 'C:\Program Files\MYCORP\MYCORP Services\Enterprise1Service'. PROPERTY CHANGE: Modifying WixLibRedirectFolder.9EFC3F5B_3D47_4233_A162_371DEF5D8E92 property. Its current value is 'C:\Program Files\MYCORP\MYCORP Services\Enterprise1Service'. Its new value: 'C:\Program Files\MYCORP\MYCORP Services\Common'. PROPERTY CHANGE: Modifying WixLibRedirectFolder.9EFC3F5B_3D47_4233_A162_371DEF5D8E92 property. Its current value is 'C:\Program Files\MYCORP\MYCORP Services\Common'. Its new value: 'C:\Program Files\MYCORP\MYCORP Services\Enterprise4Service'. PROPERTY CHANGE: Modifying WixLibRedirectFolder.9EFC3F5B_3D47_4233_A162_371DEF5D8E92 property. Its current value is 'C:\Program Files\MYCORP\MYCORP Services\Enterprise4Service'. Its new value: 'C:\Program Files\MYCORP\MYCORP Services\Common'. PROPERTY CHANGE: Modifying WixLibRedirectFolder.9EFC3F5B_3D47_4233_A162_371DEF5D8E92 property. Its current value is 'C:\Program Files\MYCORP\MYCORP Services\Common'. Its new value: 'C:\Program Files\MYCORP\MYCORP Services\Enterprise4Service'. PROPERTY CHANGE: Adding WixLibRedirectFolder.D40E1FBB_05DF_4124_9CBB_3C09B6004B44 property. Its value is 'C:\Program Files\MYCORP\MYCORP Services\Enterprise2Service'. PROPERTY CHANGE: Modifying WixLibRedirectFolder.D40E1FBB_05DF_4124_9CBB_3C09B6004B44 property. Its current value is 'C:\Program Files\MYCORP\MYCORP Services\Enterprise2Service'. Its new value: 'C:\Program Files\MYCORP\MYCORP Services\Common'. PROPERTY CHANGE: Modifying WixLibRedirectFolder.D40E1FBB_05DF_4124_9CBB_3C09B6004B44 property. Its current value is 'C:\Program Files\MYCORP\MYCORP Services\Common'. Its new value: 'C:\Program Files\MYCORP\MYCORP Services\Enterprise4Service'. PROPERTY CHANGE: Modifying WixLibRedirectFolder.D40E1FBB_05DF_4124_9CBB_3C09B6004B44 property. Its current value is 'C:\Program Files\MYCORP\MYCORP Services\Enterprise4Service'. Its new value: 'C:\Program Files\MYCORP\MYCORP Services\Common'. PROPERTY CHANGE: Modifying WixLibRedirectFolder.D40E1FBB_05DF_4124_9CBB_3C09B6004B44 property. Its current value is 'C:\Program Files\MYCORP\MYCORP Services\Common'. Its new value: 'C:\Program Files\MYCORP\MYCORP Services\Enterprise4Service'. PROPERTY CHANGE: Adding WixLibRedirectFolder.21C4128B_7484_4589_ABC5_E3FA2A95D2B6 property. Its value is 'C:\Program Files\MYCORP\MYCORP Services\Enterprise3Service'. PROPERTY CHANGE: Modifying WixLibRedirectFolder.21C4128B_7484_4589_ABC5_E3FA2A95D2B6 property. Its current
Re: [WiX-users] Redisplay MSI's UI when Bootstrapper is run a second time
On 29-Jan-13 16:10, Karl Werner wrote: However, still stuck on the original problem - How can I get the MSI's UI invoked on the second run of the bootstrapper. You can't. Burn needs to know the operation being performed which it can't if the operation is determined during the execution of the package. -- sig://boB http://joyofsetup.com/ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Speed vs Stability: Large numbers of components
On 25-Jan-13 10:44, Hoover, Jacob wrote: I currently have a single MSI with ~30k components. During installations and major upgrades it appears the sheer number of components is causing performance issues (the files are data files so there aren't version info headers). What is the best way of increasing installation and updates performance without sacrificing best practices (one file per component)? Would breaking the install into multiple MSI's provide any benefit even though all of the MSI's would need to be installed? Would embedding the data into multiple DLLs with version info be worth the effort? (Most of the files are 1kb, but I believe Windows installer hashes the files if they don't have version info and the create and modify timestamps are the same.) Are there any other options available? Above 7000 or 8000 components, MSI starts to exhibit really awful performance during costing. Multiple MSIs would prevent that. But it's still a problem outside of setup. One of my past projects had this problem and we decided to fix it using zip files to combine multiple data files; that fixed setup and development and testing. -- sig://boB http://joyofsetup.com/ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixShellExec not running application on exit
On 28-Jan-13 16:24, John J. Hughes II wrote: I have searched the web for Error 2896 which seems to say it is a UAC problem but I also found references that say WixShellExec which prompt if need for UAC permission so I would not expect that to be a problem but I am new to the toolset. Hopefully none of these references was in the WiX doc. Immediate custom actions cannot launch elevated processes, regardless of manifesting. -- sig://boB http://joyofsetup.com/ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExePackage that requires .NET installed earlier in Bundle
On 29-Jan-13 17:39, Eric Schultz wrote: If .Net Framework 4 is already installed, SQL Server installs fine. If .Net Framework 4 is not installed, the SQL Server Express install fails because it says the .Net Framework is not installed. In fact, it says it needs the exact same version as was just installed in the previous step. Check the Burn log to see if a reboot was required (and suppressed). If so, it won't be real until after the reboot. -- sig://boB http://joyofsetup.com/ -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Speed vs Stability: Large numbers of Components
I'm in a similar situation with close to 30,000 files to deploy of which perhaps 50 - 100 are DLL's, EXE, OCX etc. I've ended up grouping files together in a component, (with the exception of DLL's etc) sometimes up to 5,000 or 6,000 in one component. I also forced a version number for each file to ensure that if I had to perform an upgrade the file would be overwritten REGARDLESS if it had changed forcing integrity of the application. I've also disabled the repair option from ARP, but allow Repair from 'Change' and modified the ReinstallMode to anus. In my situation these deployed files are not updated by the application and should not be modified by the customer. If they have been modified by the customer I need the repair to restore the install back to deployment status. I would like to know the 'optimal' amount of files that should be contained in 1 component. As much as I'd love to give each file a unique component, filling the registry with 30,000 GUIDS just seems crazy. Neil -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ExePackage that requires .NET installed earlier in Bundle
I think you'll find that SQL 2008 requires .NET 3.5 to be installed (SQL 2012 will work with .NET 3.5 or 4.0). Neil I'm creating a Bundle that installs the .NET Framework 4 and then SQL Server Express as needed. The Chain element looks as follows: Chain PackageGroupRef Id=NetFx40Redist/ ExePackage InstallCommand=.. Id=SqlExpress2008x64 DetectCondition=(On x64 and needed) PerMachine=yes DownloadUrl=..url.. SourceFile=redist\SQLEXPR_x64_ENU.exe Name=redist\SQLEXPR_x64_ENU.exe Compressed=no/ ExePackage InstallCommand=... Id=SqlExpress2008 Name=redist\SQLEXPR_x86_ENU.exe Compressed=no DetectCondition=(On an x86 machine) PerMachine=yes DownloadUrl=..url.. SourceFile=redist\SQLEXPR_x86_ENU.exe/ /Chain If .Net Framework 4 is already installed, SQL Server installs fine. If .Net Framework 4 is not installed, the SQL Server Express install fails because it says the .Net Framework is not installed. In fact, it says it needs the exact same version as was just installed in the previous step. I don't know Burn very well so I'm wondering if the .Net Framework install needs to be committed in some way before it can be used by the Sql Server install. I tried putting a RollbackBoundary after the .Net install but it didn't seem to help. Any one have any suggestions? Thanks, Eric -- Eric Schultz, Developer Advocate, Outercurve Foundation http://www.outercurve.org eschu...@outercurve.org cell: 920-539-0404 skype: ericschultzwi @EricOutercurve -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
