[WiX-users] Installing outside ProgramFilesFolder
Hi I have a requirement to use C:\MyApp as the default installation directory rather than being user Program Files (x86). I also give the user the opportunity to specify a different directory. I'm using: At install time, the correct default directory of C:\MyApp is displayed (assuming the Windows volume is C:). However, if I specify a different directory (eg C:\MyApp2) during the setup then the default C:\MyApp is still used. How do I get this to work so that it defaults to C:\MyApp but the user supplied directory, if specified, is used? Thanks Gavin -- 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn and general app dependency question
Hello, I have a app A which can be installed as a standalone which I have an MSI installer for. Then I have a second app B which needs app A. For app B I have a separate MSI installer which contains a shared wixlib file that is is in app A and app B. First off, is the mentioned way correct or there is another(better) way to do the above? I would like to have something in the ARP to show up as a tree ? Like: B |->A Or 2 separate ARP entries, but not allow the uninstall of A if B is installed? Is that possible? Also is it possible with burn using the "provides" and "requires" elements? I don't quite understand how to use the "KeyString Optional unique registry key name that identifies a product version range on which other products can depend. This attribute is required in package authoring, but optional for components. " part of those elements? Which Key would it be referring to? Thanks -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-and-general-app-dependency-question-tp7581536.html Sent from the wix-users mailing list archive at Nabble.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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: Specifying PackageGroup Id on button click
Thanks, I will look into that, at the moment I'm playing around with InstallConditions and setting variables from my DA component. It sort of works but this might run into trouble later. On Tue, Oct 23, 2012 at 3:04 PM, Adrian Gantoi wrote: > Take a look at WixBA (available in the WiX source files, it's the WiX > installer UI). > You will find the PlanPackageBegin handler in InstallationViewModel.cs (at > least for WiX version 3.6 this is true). > You can set in here the state of each package from your bundle (i.e. you > can always plan LaunchAction.Install, > and depending on the button you use to start the install, set the state of > a package to "ignore it" - e.State = RequestState.None). > > > > > > From: Hans ter Horst > To: General discussion for Windows Installer XML toolset. < > wix-users@lists.sourceforge.net> > Sent: Monday, October 22, 2012 12:17 PM > Subject: Re: [WiX-users] Burn: Specifying PackageGroup Id on button click > > Thanks Rob, unfortunately I cannot find any information about > the OnPackagePlan callbacks online nor can I see it used in the WixBA > source code. Could you point me in the right direction? > > Thanks! > > On Fri, Oct 19, 2012 at 6:59 PM, Rob Mensching > wrote: > > > Check on the OnPackagePlan callbacks. > > > > On Fri, Oct 19, 2012 at 5:19 AM, Hans ter Horst > > wrote: > > > > > Hello, i have several simple installers that I would like group behind > a > > > Burn interface and start depending on the button clicked from the > > > Bootstrapper interface I am designing which will have several buttons. > > > For a simple bootstrapper I know > > > I can use Bootstrapper.Engine.Plan(LaunchAction.Install); on hitting an > > > install button and Bootstrapper.Engine.Plan(LaunchAction.Uninstall); > for > > > an uninstall button. How can I extend this to refer to PackageA or > > PackageB > > > in my Bundle.wxs file so i can differentiate between the MSI files > > started? > > > > > > Thanks! > > > -- > > > http://monochrome.me.uk/blog/ > > > > > > > > > -- > > > 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_sfd2d_oct > > > ___ > > > WiX-users mailing list > > > WiX-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > > -- > > virtually, > > > >Rob Mensching > >http://RobMensching.com LLC > > > > > -- > > 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_sfd2d_oct > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > http://monochrome.me.uk/blog/ > > -- > 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_sfd2d_oct > ___ > 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_sfd2d_oct > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- http://monochrome.me.uk/blog/ -- 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn: Specifying PackageGroup Id on button click
Take a look at WixBA (available in the WiX source files, it's the WiX installer UI). You will find the PlanPackageBegin handler in InstallationViewModel.cs (at least for WiX version 3.6 this is true). You can set in here the state of each package from your bundle (i.e. you can always plan LaunchAction.Install, and depending on the button you use to start the install, set the state of a package to "ignore it" - e.State = RequestState.None). From: Hans ter Horst To: General discussion for Windows Installer XML toolset. Sent: Monday, October 22, 2012 12:17 PM Subject: Re: [WiX-users] Burn: Specifying PackageGroup Id on button click Thanks Rob, unfortunately I cannot find any information about the OnPackagePlan callbacks online nor can I see it used in the WixBA source code. Could you point me in the right direction? Thanks! On Fri, Oct 19, 2012 at 6:59 PM, Rob Mensching wrote: > Check on the OnPackagePlan callbacks. > > On Fri, Oct 19, 2012 at 5:19 AM, Hans ter Horst > wrote: > > > Hello, i have several simple installers that I would like group behind a > > Burn interface and start depending on the button clicked from the > > Bootstrapper interface I am designing which will have several buttons. > > For a simple bootstrapper I know > > I can use Bootstrapper.Engine.Plan(LaunchAction.Install); on hitting an > > install button and Bootstrapper.Engine.Plan(LaunchAction.Uninstall); for > > an uninstall button. How can I extend this to refer to PackageA or > PackageB > > in my Bundle.wxs file so i can differentiate between the MSI files > started? > > > > Thanks! > > -- > > http://monochrome.me.uk/blog/ > > > > > -- > > 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_sfd2d_oct > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > virtually, > > Rob Mensching > http://RobMensching.com LLC > > -- > 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_sfd2d_oct > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- http://monochrome.me.uk/blog/ -- 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_sfd2d_oct ___ 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn and Files in Use / Restart Manager
Hello Neil, thanks again for your help. If I have some time I will implement this feature. Maybe someone else will find it useful too. Regards, Georg -Ursprüngliche Nachricht- Von: Neil Sleightholm [mailto:n...@x2systems.com] Gesendet: Dienstag, 23. Oktober 2012 12:33 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Burn and Files in Use / Restart Manager I see the problem, what you would probably need is a close application function within the bootstrapper - not something that is available today (may be add it as a feature request). Not pretty but you could block the install if Outlook is running (not entirely sure how to detect that) and get the user to shut it down before the install will run. Neil -Original Message- From: Georg von Kries [mailto:g...@creativbox.net] Sent: 23 October 2012 10:19 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Burn and Files in Use / Restart Manager Hi Neil, thanks for your suggestion. In my case there is an Outlook add-in installed together with our application. We cannot just close Outlook without asking the user and I don't see a possibility to show just a single internal MSI dialog for prompting the user to close Outlook. Am I missing something here? Regards, Georg -Ursprüngliche Nachricht- Von: Neil Sleightholm [mailto:n...@x2systems.com] Gesendet: Dienstag, 23. Oktober 2012 08:09 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Burn and Files in Use / Restart Manager What I do in this scenario is scan the logs to find out what files are in use and causing the reboot - look for a return code of 3010 from one of your MSIs - burn will only do a reboot if one of the packages (MSI or EXE) requests it. Once you know that you can decide how to handle it more effectively. For example, if a service is running you can stop it, if it is an application you can use the WiX CloseApplication element. Hope this helps. Neil -Original Message- From: Georg von Kries [mailto:g...@creativbox.net] Sent: 22 October 2012 21:15 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Burn and Files in Use / Restart Manager Hi all, I've been successfully using WiX for a long time now and I'm very happy with it. Many thanks for all the effort you are putting into this project. Currently I'm using WiX together with a standard Visual Studio bootstrapper for .NET and other prerequisites. I want to replace this with Burn which seems to be a very nice solution. All is working very good and using Burn is mostly straightforward. But one thing bothers me: There seems to be no standard way for dealing with files in use and especially together with the restart manager. Burn will by default always trigger a restart/ask for restarting if something is in use. For normal applications this is very annoying for users. Additionally if I remember correctly there was a Windows logo requirement which disallows this practice. Therefore I'm currently trying to extend the standard bootstrapper application (unmanaged) with "files in use" and restart manager capabilities. My current understanding is that this is not possible for an bootstrapper application without changing the engine. E.g. it seems OnExecuteFilesInUse() is never called for MSI packages; not even thinking about the Windows installer message INSTALLMESSAGE_RMFILESINUSE for using restart manager. I'm no windows installer or WiX guru, but when looking at the Burn source there is no message filter added for either INSTALLLOG_FILESINUSE or (if supported by the installer version) INSTALLLOGMODE_RMFILESINUSE when the external UI is initialized. But I might be missing something here. I've started playing around with the Burn 3.7 source (because it's using MSBuild only) and got the messages working, but there are other side effects. E.g. the engine will always suppress results from the UI trying to pass only expected values back to the installer; but in case of the restart manager there are more possibilities which are not included into the message. I just wanted to ask what the plans are for supporting this functionality or if I'm totally going into the wrong direction and there is an obvious solution I'm not aware of. Thanks for reading! Yours sincerely, Georg von Kries -- 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_sfd2d_oct ___ 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/appd
Re: [WiX-users] ServiceInstaller for harvested file
Super! Thanks Peter... that helps with the initial fiddly bits like namespaces and some typical XPath queries. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, 23 October 2012 9:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstaller for harvested file Here's an extract we use to tidy up a heated help files. It's no use in itself but you can see a way to handle namespaces, select Wix elements, etc. http://www.w3.org/1999/XSL/Transform"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:wix="http://schemas.microsoft.com/wix/2006/wi"; exclude-result-prefixes="wix xs"> http://schemas.microsoft.com/wix/2006/wi"; > http://schemas.microsoft.com/wix/2006/wi"; > $(var.libName)=$(var.SdlBuildNumber) -Original Message- From: Johann A. Hough [mailto:joh...@silverskysoftware.com.au] Sent: 23 October 2012 11:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstaller for harvested file Thanks all I've started looking at using an XSLT transformation - it's been years since I had to write XSL so it'll be slow going initially. Is there perhaps a set of WiX XSL examples available somewhere? -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, 23 October 2012 4:25 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstaller for harvested file Retrying this as the last attempt bounced.. If you are using heat you could provide it with a -t and an XSLT transform which would be used to tweak the default output to your liking. This would allow you to only have the need for the generated file. Jacob -Original Message- From: Johann A. Hough [mailto:joh...@silverskysoftware.com.au] Sent: Monday, October 22, 2012 9:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ServiceInstaller for harvested file Hi all I've started the arduous process of recreating a new installer using WiX to replace our existing VS2010 Setup Projects. Unfortunately it's not been smooth sailing, because to be able to create some basic installation capabilities like dependencies discovery, website installation, content harvesting, etc. has taken a lot of time and research. I've bridged most of those with various solutions from the web, but have now struck out with the installation of a service. Specifically we harvest content and dependencies using heat (during Build Event) because website projects, and other projects have content that regularly change) and it's simply not feasible to manually update the .WXS file for those changes. One of those projects for installation is a Windows service (in fact it's a .NET Service with a ServiceInstaller implemented). The frustration I'm having is being able to point to the service executable, without having to place the for it inside the generated (harvested) .WXS file (within in the same for the ). Given my relatively basic understanding of WiX I'm wondering if there is a way to reference that component in a fragment or something so that the can find the service it needs to install. Stating the same problem differently, the pointing to the Service executable is located in one .WXS (a generated one) and the for it is located in another .WXS file (manually maintained) - how can I marry the Service Install to make it work? I also have another question regarding some of the properties for Service Install - and I'm not sure why they are there, for example DisplayName, Description, Account, etc. - these are already defined in the .NET ServiceInstaller code and should just be used not so? Thanks all Johann - - 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_sfd2d_oct ___ 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.
Re: [WiX-users] ServiceInstaller for harvested file
Here's an extract we use to tidy up a heated help files. It's no use in itself but you can see a way to handle namespaces, select Wix elements, etc. http://www.w3.org/1999/XSL/Transform"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns:wix="http://schemas.microsoft.com/wix/2006/wi"; exclude-result-prefixes="wix xs"> http://schemas.microsoft.com/wix/2006/wi"; > http://schemas.microsoft.com/wix/2006/wi"; > $(var.libName)=$(var.SdlBuildNumber) -Original Message- From: Johann A. Hough [mailto:joh...@silverskysoftware.com.au] Sent: 23 October 2012 11:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstaller for harvested file Thanks all I've started looking at using an XSLT transformation - it's been years since I had to write XSL so it'll be slow going initially. Is there perhaps a set of WiX XSL examples available somewhere? -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, 23 October 2012 4:25 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstaller for harvested file Retrying this as the last attempt bounced.. If you are using heat you could provide it with a -t and an XSLT transform which would be used to tweak the default output to your liking. This would allow you to only have the need for the generated file. Jacob -Original Message- From: Johann A. Hough [mailto:joh...@silverskysoftware.com.au] Sent: Monday, October 22, 2012 9:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ServiceInstaller for harvested file Hi all I've started the arduous process of recreating a new installer using WiX to replace our existing VS2010 Setup Projects. Unfortunately it's not been smooth sailing, because to be able to create some basic installation capabilities like dependencies discovery, website installation, content harvesting, etc. has taken a lot of time and research. I've bridged most of those with various solutions from the web, but have now struck out with the installation of a service. Specifically we harvest content and dependencies using heat (during Build Event) because website projects, and other projects have content that regularly change) and it's simply not feasible to manually update the .WXS file for those changes. One of those projects for installation is a Windows service (in fact it's a .NET Service with a ServiceInstaller implemented). The frustration I'm having is being able to point to the service executable, without having to place the for it inside the generated (harvested) .WXS file (within in the same for the ). Given my relatively basic understanding of WiX I'm wondering if there is a way to reference that component in a fragment or something so that the can find the service it needs to install. Stating the same problem differently, the pointing to the Service executable is located in one .WXS (a generated one) and the for it is located in another .WXS file (manually maintained) - how can I marry the Service Install to make it work? I also have another question regarding some of the properties for Service Install - and I'm not sure why they are there, for example DisplayName, Description, Account, etc. - these are already defined in the .NET ServiceInstaller code and should just be used not so? Thanks all Johann - - 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_sfd2d_oct ___ 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_sfd2d_oct ___ 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.s
Re: [WiX-users] ServiceInstaller for harvested file
Thanks all I've started looking at using an XSLT transformation - it's been years since I had to write XSL so it'll be slow going initially. Is there perhaps a set of WiX XSL examples available somewhere? -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, 23 October 2012 4:25 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstaller for harvested file Retrying this as the last attempt bounced.. If you are using heat you could provide it with a -t and an XSLT transform which would be used to tweak the default output to your liking. This would allow you to only have the need for the generated file. Jacob -Original Message- From: Johann A. Hough [mailto:joh...@silverskysoftware.com.au] Sent: Monday, October 22, 2012 9:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ServiceInstaller for harvested file Hi all I've started the arduous process of recreating a new installer using WiX to replace our existing VS2010 Setup Projects. Unfortunately it's not been smooth sailing, because to be able to create some basic installation capabilities like dependencies discovery, website installation, content harvesting, etc. has taken a lot of time and research. I've bridged most of those with various solutions from the web, but have now struck out with the installation of a service. Specifically we harvest content and dependencies using heat (during Build Event) because website projects, and other projects have content that regularly change) and it's simply not feasible to manually update the .WXS file for those changes. One of those projects for installation is a Windows service (in fact it's a .NET Service with a ServiceInstaller implemented). The frustration I'm having is being able to point to the service executable, without having to place the for it inside the generated (harvested) .WXS file (within in the same for the ). Given my relatively basic understanding of WiX I'm wondering if there is a way to reference that component in a fragment or something so that the can find the service it needs to install. Stating the same problem differently, the pointing to the Service executable is located in one .WXS (a generated one) and the for it is located in another .WXS file (manually maintained) - how can I marry the Service Install to make it work? I also have another question regarding some of the properties for Service Install - and I'm not sure why they are there, for example DisplayName, Description, Account, etc. - these are already defined in the .NET ServiceInstaller code and should just be used not so? Thanks all Johann -- 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_sfd2d_oct ___ 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_sfd2d_oct ___ 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing a mixed 32 and 64 bit Application
Give each MSI its own product and upgrade code so that one doesn't upgrade the other. -Original Message- From: Martin Johnson [mailto:mjohn...@mpjconsultancy.com] Sent: 23 October 2012 11:00 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installing a mixed 32 and 64 bit Application My application has recently become a mixed 32 and 64 bit application. Seeing as this cannot be done in a single msi, I have migrated to WiX3.6 and assembled a bootstrapper. The 32 bit install succeeds and I have implemented the 64 bit as a major upgrade, my problem is that when executed the 64 bit removes the 32 bit installation. I'm not sure whether I am missing something basic in my design or whether my whole approach is incorrect. Any hints tips or suggestions would be welcomed. Martin - - 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_sfd2d_oct ___ 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. -- 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Environment variables for local installs
Look into the Environment element in the Wix help. -Original Message- From: Timothy Madden [mailto:terminato...@gmail.com] Sent: 23 October 2012 10:51 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Environment variables for local installs Hello I have a script where I want to install a new file name extension (.exim) and add it to PATHEXT, so cmd.exe can launch files with that extension by their name only, as commands. I would also like to offer both "all users" and "current user" installation for my program. To my big surprise, on my Windows XP system, after I create the PATHEXT environment variable for the current user, with the contents: PATHEXT=.exim the user automatically loses the contents found in the system variable PATHEXT (which is usually .COM;.EXE;.BAT;.CMD, plus whatever other languages (perl, ruby) the user has installed). Is there a way for a local install (current-user only) to add the new extension only for the current user, but still use the variable value from the system variables ? Do other versions of Windows show this problem ? Can I use an REG_EXPAND_SZ value in the registry, like: %PATHEXT%;.exim in order to merge the PATHEXT variables from both (user and system) environments ? Can I find some WiX code that can do the following for user-only installations: - on install: - if the user-local variable PATHEXT does not exit, create it with the value: %PATHEXT%;.exim on install, - only add ";.exim" to the variable if the variable is already present and does not include ";.exim" - on uninstall - remove ".exim" from the value of the variable - if the remaining value of the variable is %PATHEXT% only, remove the variable Thank you, Timothy Madden - - 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_sfd2d_oct ___ 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. -- 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn and Files in Use / Restart Manager
I see the problem, what you would probably need is a close application function within the bootstrapper - not something that is available today (may be add it as a feature request). Not pretty but you could block the install if Outlook is running (not entirely sure how to detect that) and get the user to shut it down before the install will run. Neil -Original Message- From: Georg von Kries [mailto:g...@creativbox.net] Sent: 23 October 2012 10:19 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Burn and Files in Use / Restart Manager Hi Neil, thanks for your suggestion. In my case there is an Outlook add-in installed together with our application. We cannot just close Outlook without asking the user and I don't see a possibility to show just a single internal MSI dialog for prompting the user to close Outlook. Am I missing something here? Regards, Georg -Ursprüngliche Nachricht- Von: Neil Sleightholm [mailto:n...@x2systems.com] Gesendet: Dienstag, 23. Oktober 2012 08:09 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Burn and Files in Use / Restart Manager What I do in this scenario is scan the logs to find out what files are in use and causing the reboot - look for a return code of 3010 from one of your MSIs - burn will only do a reboot if one of the packages (MSI or EXE) requests it. Once you know that you can decide how to handle it more effectively. For example, if a service is running you can stop it, if it is an application you can use the WiX CloseApplication element. Hope this helps. Neil -Original Message- From: Georg von Kries [mailto:g...@creativbox.net] Sent: 22 October 2012 21:15 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Burn and Files in Use / Restart Manager Hi all, I've been successfully using WiX for a long time now and I'm very happy with it. Many thanks for all the effort you are putting into this project. Currently I'm using WiX together with a standard Visual Studio bootstrapper for .NET and other prerequisites. I want to replace this with Burn which seems to be a very nice solution. All is working very good and using Burn is mostly straightforward. But one thing bothers me: There seems to be no standard way for dealing with files in use and especially together with the restart manager. Burn will by default always trigger a restart/ask for restarting if something is in use. For normal applications this is very annoying for users. Additionally if I remember correctly there was a Windows logo requirement which disallows this practice. Therefore I'm currently trying to extend the standard bootstrapper application (unmanaged) with "files in use" and restart manager capabilities. My current understanding is that this is not possible for an bootstrapper application without changing the engine. E.g. it seems OnExecuteFilesInUse() is never called for MSI packages; not even thinking about the Windows installer message INSTALLMESSAGE_RMFILESINUSE for using restart manager. I'm no windows installer or WiX guru, but when looking at the Burn source there is no message filter added for either INSTALLLOG_FILESINUSE or (if supported by the installer version) INSTALLLOGMODE_RMFILESINUSE when the external UI is initialized. But I might be missing something here. I've started playing around with the Burn 3.7 source (because it's using MSBuild only) and got the messages working, but there are other side effects. E.g. the engine will always suppress results from the UI trying to pass only expected values back to the installer; but in case of the restart manager there are more possibilities which are not included into the message. I just wanted to ask what the plans are for supporting this functionality or if I'm totally going into the wrong direction and there is an obvious solution I'm not aware of. Thanks for reading! Yours sincerely, Georg von Kries -- 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_sfd2d_oct ___ 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_sfd2d_oct ___ 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 fre
[WiX-users] Installing a mixed 32 and 64 bit Application
My application has recently become a mixed 32 and 64 bit application. Seeing as this cannot be done in a single msi, I have migrated to WiX3.6 and assembled a bootstrapper. The 32 bit install succeeds and I have implemented the 64 bit as a major upgrade, my problem is that when executed the 64 bit removes the 32 bit installation. I'm not sure whether I am missing something basic in my design or whether my whole approach is incorrect. Any hints tips or suggestions would be welcomed. Martin -- 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installing a mixed 32 and 64 bit Application
My application has recently become a mixed 32 and 64 bit application. Seeing as this cannot be done in a single msi, I have migrated to WiX3.6 and assembled a bootstrapper. The 32 bit install succeeds and I have implemented the 64 bit as a major upgrade, my problem is that when executed the 64 bit removes the 32 bit installation. I'm not sure whether I am missing something basic in my design or whether my whole approach is incorrect. Any hints tips or suggestions would be welcomed. Martin -- 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Environment variables for local installs
Hello I have a script where I want to install a new file name extension (.exim) and add it to PATHEXT, so cmd.exe can launch files with that extension by their name only, as commands. I would also like to offer both "all users" and "current user" installation for my program. To my big surprise, on my Windows XP system, after I create the PATHEXT environment variable for the current user, with the contents: PATHEXT=.exim the user automatically loses the contents found in the system variable PATHEXT (which is usually .COM;.EXE;.BAT;.CMD, plus whatever other languages (perl, ruby) the user has installed). Is there a way for a local install (current-user only) to add the new extension only for the current user, but still use the variable value from the system variables ? Do other versions of Windows show this problem ? Can I use an REG_EXPAND_SZ value in the registry, like: %PATHEXT%;.exim in order to merge the PATHEXT variables from both (user and system) environments ? Can I find some WiX code that can do the following for user-only installations: - on install: - if the user-local variable PATHEXT does not exit, create it with the value: %PATHEXT%;.exim on install, - only add ";.exim" to the variable if the variable is already present and does not include ";.exim" - on uninstall - remove ".exim" from the value of the variable - if the remaining value of the variable is %PATHEXT% only, remove the variable Thank you, Timothy Madden -- 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn and Files in Use / Restart Manager
Hi Neil, thanks for your suggestion. In my case there is an Outlook add-in installed together with our application. We cannot just close Outlook without asking the user and I don't see a possibility to show just a single internal MSI dialog for prompting the user to close Outlook. Am I missing something here? Regards, Georg -Ursprüngliche Nachricht- Von: Neil Sleightholm [mailto:n...@x2systems.com] Gesendet: Dienstag, 23. Oktober 2012 08:09 An: General discussion for Windows Installer XML toolset. Betreff: Re: [WiX-users] Burn and Files in Use / Restart Manager What I do in this scenario is scan the logs to find out what files are in use and causing the reboot - look for a return code of 3010 from one of your MSIs - burn will only do a reboot if one of the packages (MSI or EXE) requests it. Once you know that you can decide how to handle it more effectively. For example, if a service is running you can stop it, if it is an application you can use the WiX CloseApplication element. Hope this helps. Neil -Original Message- From: Georg von Kries [mailto:g...@creativbox.net] Sent: 22 October 2012 21:15 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Burn and Files in Use / Restart Manager Hi all, I've been successfully using WiX for a long time now and I'm very happy with it. Many thanks for all the effort you are putting into this project. Currently I'm using WiX together with a standard Visual Studio bootstrapper for .NET and other prerequisites. I want to replace this with Burn which seems to be a very nice solution. All is working very good and using Burn is mostly straightforward. But one thing bothers me: There seems to be no standard way for dealing with files in use and especially together with the restart manager. Burn will by default always trigger a restart/ask for restarting if something is in use. For normal applications this is very annoying for users. Additionally if I remember correctly there was a Windows logo requirement which disallows this practice. Therefore I'm currently trying to extend the standard bootstrapper application (unmanaged) with "files in use" and restart manager capabilities. My current understanding is that this is not possible for an bootstrapper application without changing the engine. E.g. it seems OnExecuteFilesInUse() is never called for MSI packages; not even thinking about the Windows installer message INSTALLMESSAGE_RMFILESINUSE for using restart manager. I'm no windows installer or WiX guru, but when looking at the Burn source there is no message filter added for either INSTALLLOG_FILESINUSE or (if supported by the installer version) INSTALLLOGMODE_RMFILESINUSE when the external UI is initialized. But I might be missing something here. I've started playing around with the Burn 3.7 source (because it's using MSBuild only) and got the messages working, but there are other side effects. E.g. the engine will always suppress results from the UI trying to pass only expected values back to the installer; but in case of the restart manager there are more possibilities which are not included into the message. I just wanted to ask what the plans are for supporting this functionality or if I'm totally going into the wrong direction and there is an obvious solution I'm not aware of. Thanks for reading! Yours sincerely, Georg von Kries -- 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_sfd2d_oct ___ 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_sfd2d_oct ___ 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ServiceInstaller for harvested file
-Original Message- From: Peter Shirtcliffe Sent: 22 October 2012 16:15 To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] ServiceInstaller for harvested file You shouldn't user ServiceInstaller to install a service unless Wix provides no way to do everything you need to. Use the Wix ServiceInstall element instead. You do have to be careful to separate configuration from (the unchanging aspects of) installation. You must ensure that you're obeying Component Rules if you're generating component definitions. In case you weren't aware, you don't have to put all the files that comprise a service into a single component, nor should you. Stick to one file per component. Would your physical service vary so often that a component consisting of 1 file element and 1 service install element would need to change ? I'd expect the physical architecture to change often during the early days of a project, but it ought to settle down in time. The answer to your question is that you can use to insert a .wxi comprising a single file element inside an include, but you possibly shouldn't :) See the Preprocessor section of the wix help. An alternative solution that is widely applicable is to apply XSL transformations to your .wxs files. Heat even has a command line argument to make it easy to apply one if you can live with XSLT version 1.0. -Original Message- From: Johann A. Hough [mailto:joh...@silverskysoftware.com.au] Sent: 22 October 2012 15:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] ServiceInstaller for harvested file Hi all I've started the arduous process of recreating a new installer using WiX to replace our existing VS2010 Setup Projects. Unfortunately it's not been smooth sailing, because to be able to create some basic installation capabilities like dependencies discovery, website installation, content harvesting, etc. has taken a lot of time and research. I've bridged most of those with various solutions from the web, but have now struck out with the installation of a service. Specifically we harvest content and dependencies using heat (during Build Event) because website projects, and other projects have content that regularly change) and it's simply not feasible to manually update the .WXS file for those changes. One of those projects for installation is a Windows service (in fact it's a .NET Service with a ServiceInstaller implemented). The frustration I'm having is being able to point to the service executable, without having to place the for it inside the generated (harvested) .WXS file (within in the same for the ). Given my relatively basic understanding of WiX I'm wondering if there is a way to reference that component in a fragment or something so that the can find the service it needs to install. Stating the same problem differently, the pointing to the Service executable is located in one .WXS (a generated one) and the for it is located in another .WXS file (manually maintained) - how can I marry the Service Install to make it work? I also have another question regarding some of the properties for Service Install - and I'm not sure why they are there, for example DisplayName, Description, Account, etc. - these are already defined in the .NET ServiceInstaller code and should just be used not so? Thanks all Johann - - 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_sfd2d_oct ___ 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. -- 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_sfd2d_oct ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting started writing a custom Bootstrapper interface
Hi Igor,
I allready guessed that... unfortunately not much developers create such things
for Open Source or Free Software projects :-(
But thanks for telling us about your BA design and the decisions you took! That
also helps :-)
Best regards,
Christian
-Ursprüngliche Nachricht-
Von: Igor Brejc [mailto:igor.br...@gmail.com]
Gesendet: Dienstag, 23. Oktober 2012 10:13
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Getting started writing a custom Bootstrapper interface
Hi Christian,
Unfortunately I cannot release the source code, it's the property of the
company I work for.
Best regards,
Igor
On Mon, Oct 22, 2012 at 8:30 AM, Christian Hausknecht < chauskne...@beracom.de>
wrote:
> Hello Igor,
>
> is there any chance that you could provide us the source code?
>
> Bets regards,
>
> Christian
>
>
> -Ursprüngliche Nachricht-
> Von: Igor Brejc [mailto:igor.br...@gmail.com]
> Gesendet: Samstag, 20. Oktober 2012 20:04
> An: General discussion for Windows Installer XML toolset.
> Betreff: Re: [WiX-users] Getting started writing a custom Bootstrapper
> interface
>
> Hi,
>
> Some more pointers from me. I've implemented a custom managed
> bootstrapper using WinForms. The GUI actually looks pretty much the
> same as the standard MSI setup wizard, but implemented with custom C#
> code using MVP
> (model-view-presenter) pattern. This enables me to unit-test the
> wizard without actually running the installation.
>
> I've also "hidden" the WiX bootstrapper engine behind an adapter
> interface (I called it IInstallEngine). This way I can run the wizard as a
> "normal"
> Windows Forms application and click through it (again, without the
> need to run the actual Windows installation), since in that mode the
> wizard uses a mocked implementation of IInstallEngine. I just simply
> added the static Main method which has the similar logic to the Run().
>
> (Note to Rob: perhaps it would be a good idea to change the design of
> the managed bootstrapper so that it works with interfaces instead of
> concrete implementations, this would be really helpful for unit
> testing and simulation).
>
> The wizard has one added feature: a debug window which can be turned
> on through the command line and displays all the install log messages
> directly in the setup wizard.
>
> The documentation for the managed BS is pretty scarce, so I had to
> look into WiX's source code and do a lot of trials and errors to get
> to this point (and I still have some issues to work through).
>
> Best regards,
> Igor Brejc
>
> On Fri, Oct 19, 2012 at 10:39 AM, Hans ter Horst >wrote:
>
> > Thanks Daniel, this is precisely what I needed!
> >
> > On Fri, Oct 19, 2012 at 9:32 AM, Daniel Bruce
> > > >wrote:
> >
> > > To resolve Microsoft.Tools.WindowsInstallerXml.Bootstrapper, you
> > > need to add a reference to BootstrapperCore, which in my
> > > installation was located under C:\Program Files (x86)\WiX Toolset
> v3.7\SDK\BootstrapperCore.dll.
> > You
> > > should be able to find yours in a similar location.
> > >
> > > You are correct that there is little information about how to get
> > > started with Burn, and the little information there is to find is
> > > scattered
> > around
> > > the net and pretty terse, so I'll give you enough to get started,
> > > then
> > you
> > > should be able to look at the source code for the WiX BA to
> > > continue (I highly recommend having the source around to look at
> > > either way, because there is really no other way to get
> > > information about most
> things).
> > >
> > > For my WPF-based bootstrapper interface, I started a regular WPF
> > > application project and changed its output type to "class library".
> > > Then
> > I
> > > have a class that inherits from BootstrapperApplication looking
> > > something like this:
> > >
> > > public class MyBA : BootstrapperApplication {
> > > static public Threading.Dispatcher Dispatcher { get; private set; }
> > > static public View.InstallerWindow Window { get; private set; }
> > > static public App TheApp { get; private set; }
> > >
> > > protected override void Run()
> > > {
> > > TheApp = new App();
> > > TheApp.InitializeComponent();
> > > // Send a reference to the Application to access things,
> > > if necessary
> > > TheApp.BA = this;
> > > MyBA.Dispatcher = Threading.Dispatcher.CurrentDispatcher;
> > > TheApp.Run();
> > > this.Engine.Quit(TheApp.ExitCode);
> > > }
> > > }
> > >
> > > And in my WPF Application class I have code like this to bring up
> > > a
> > pretty
> > > standard MVVM application window:
> > >
> > > public partial class App : Application {
> > > public View.InstallerWindow Window { get; private set; }
> > > public
> > > Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperAppli
> > > ca
> > > tion
> > BA
> > > { get; set; }
> > > public int ExitCode
> > >
Re: [WiX-users] Getting started writing a custom Bootstrapper interface
Hi Christian,
Unfortunately I cannot release the source code, it's the property of the
company I work for.
Best regards,
Igor
On Mon, Oct 22, 2012 at 8:30 AM, Christian Hausknecht <
chauskne...@beracom.de> wrote:
> Hello Igor,
>
> is there any chance that you could provide us the source code?
>
> Bets regards,
>
> Christian
>
>
> -Ursprüngliche Nachricht-
> Von: Igor Brejc [mailto:igor.br...@gmail.com]
> Gesendet: Samstag, 20. Oktober 2012 20:04
> An: General discussion for Windows Installer XML toolset.
> Betreff: Re: [WiX-users] Getting started writing a custom Bootstrapper
> interface
>
> Hi,
>
> Some more pointers from me. I've implemented a custom managed bootstrapper
> using WinForms. The GUI actually looks pretty much the same as the standard
> MSI setup wizard, but implemented with custom C# code using MVP
> (model-view-presenter) pattern. This enables me to unit-test the wizard
> without actually running the installation.
>
> I've also "hidden" the WiX bootstrapper engine behind an adapter interface
> (I called it IInstallEngine). This way I can run the wizard as a "normal"
> Windows Forms application and click through it (again, without the need to
> run the actual Windows installation), since in that mode the wizard uses a
> mocked implementation of IInstallEngine. I just simply added the static
> Main method which has the similar logic to the Run().
>
> (Note to Rob: perhaps it would be a good idea to change the design of the
> managed bootstrapper so that it works with interfaces instead of concrete
> implementations, this would be really helpful for unit testing and
> simulation).
>
> The wizard has one added feature: a debug window which can be turned on
> through the command line and displays all the install log messages directly
> in the setup wizard.
>
> The documentation for the managed BS is pretty scarce, so I had to look
> into WiX's source code and do a lot of trials and errors to get to this
> point (and I still have some issues to work through).
>
> Best regards,
> Igor Brejc
>
> On Fri, Oct 19, 2012 at 10:39 AM, Hans ter Horst >wrote:
>
> > Thanks Daniel, this is precisely what I needed!
> >
> > On Fri, Oct 19, 2012 at 9:32 AM, Daniel Bruce
> > > >wrote:
> >
> > > To resolve Microsoft.Tools.WindowsInstallerXml.Bootstrapper, you
> > > need to add a reference to BootstrapperCore, which in my
> > > installation was located under C:\Program Files (x86)\WiX Toolset
> v3.7\SDK\BootstrapperCore.dll.
> > You
> > > should be able to find yours in a similar location.
> > >
> > > You are correct that there is little information about how to get
> > > started with Burn, and the little information there is to find is
> > > scattered
> > around
> > > the net and pretty terse, so I'll give you enough to get started,
> > > then
> > you
> > > should be able to look at the source code for the WiX BA to continue
> > > (I highly recommend having the source around to look at either way,
> > > because there is really no other way to get information about most
> things).
> > >
> > > For my WPF-based bootstrapper interface, I started a regular WPF
> > > application project and changed its output type to "class library".
> > > Then
> > I
> > > have a class that inherits from BootstrapperApplication looking
> > > something like this:
> > >
> > > public class MyBA : BootstrapperApplication {
> > > static public Threading.Dispatcher Dispatcher { get; private set; }
> > > static public View.InstallerWindow Window { get; private set; }
> > > static public App TheApp { get; private set; }
> > >
> > > protected override void Run()
> > > {
> > > TheApp = new App();
> > > TheApp.InitializeComponent();
> > > // Send a reference to the Application to access things, if
> > > necessary
> > > TheApp.BA = this;
> > > MyBA.Dispatcher = Threading.Dispatcher.CurrentDispatcher;
> > > TheApp.Run();
> > > this.Engine.Quit(TheApp.ExitCode);
> > > }
> > > }
> > >
> > > And in my WPF Application class I have code like this to bring up a
> > pretty
> > > standard MVVM application window:
> > >
> > > public partial class App : Application {
> > > public View.InstallerWindow Window { get; private set; }
> > > public
> > > Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperApplica
> > > tion
> > BA
> > > { get; set; }
> > > public int ExitCode
> > > {
> > > get
> > > {
> > > return state.InstallerResult;
> > > }
> > > }
> > >
> > > private InstallationState state;
> > >
> > > protected override void OnStartup(StartupEventArgs e)
> > > {
> > > base.OnStartup(e);
> > >
> > > InstallationState state = new InstallationState(BA, ...);
> > > this.state = state;
> > > InstallerViewModel vm = new InstallerViewModel(state, ...,
> > > Threading.Dispatcher.CurrentDispatcher);
> > > var Window = new View.InstallerWindow(vm);
> > >
