[wix-users] Request for additional information on installing WiX Bootstrapper prerequisite before displaying the UI

[Rob Mensching]

I'm still unclear exactly what you want exactly. If you want to build a Managed BA that has more dependencies that NETFX then you've basically found the code that does that in mbapreq (which is wixstdba run slightly differently). If you want a way to declare some packages as "prerequisites" for your software, then just install them as part of the chain.

I'm glad the short message I sent from my phone from a customer onsite was able to help you find the code in the WiX toolset. Happy Holidays.

_____________________________________________________________
 Short replies here. Complete answers over there: http://www.firegiant.com/


-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Ben Key
Sent: Thursday, December 10, 2015 7:50 PM
To: wix-users at lists.wixtoolset.org
Subject: [wix-users] Request for additional information on installing WiX Bootstrapper prerequisite before displaying the UI

Yesterday I asked a question about whether or not it is possible to have one or more prerequisites installed before the Burn custom user interface.
The specific scenario I have in mind is that the custom user interface depends on the prerequisites. Unfortunately, the responses I received were excessively vague.


However, I believe I finally have enough information to be able to give a definite answer to the question of whether or not it is possible to use Burn to install a prerequisite before the Custom UI is displayed. The responses did contain all the necessary pieces of the puzzle. I just needed to do more research and pondering in order to put the puzzle together.


First, I will give some information on the pieces of the puzzle that helped me to figure this out.


One response to my question here on the WiX-Users group included an extremely vague reference to “mba (the managed bootstrapper application host and friends)” with no links to help me to interpret this. A Google search for “WiX managed bootstrapper application” yielded thousands of results. Most of them did not reference the concept of prerequisites at all and thus did not help much. However, I eventually did find the article Introducing Managed Bootstrapper Applications <http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx>,
which indirectly references the concept of prerequisites in that the WixMbaPrereqPackageId WixVariable is used. A Google search revealed that this variable is used to define the package group that the managed bootstrapper application depends on.


Another response to my question here on the WiX-Users group suggested that I “look at ExePackage/@PrereqSupportPackage for adding multiple packages to the prereq installer prior to loading the mba.” Again, no links were provided to help me to interpret this response and a Google search proved to be only a little more helpful. A search for PrereqSupportPackage led me to the documentation for PrereqSupportPackage Attribute (Bal Extension) <http://wixtoolset.org/documentation/manual/v3/xsd/bal/prereqsupportpackage.html>
which contains the following extremely unhelpful information.

When set to "yes", the Prereq BA will plan the package to be installed if its InstallCondition is "true" or empty.

That description is entirely unhelpful since it does not describe its purpose. The only clue is that it contains the magical word prereq.


Another result in my Google search for PrereqSupportPackage was an earlier question here on the WiX-Users mailing list titled Installing .Net 4.0.3 Prerequisites required for managed bootstrapper <http://wix-users.narkive.com/qicV1CkE/installing-net-4-0-3-prerequisites-required-for-managed-bootstrapper>.
There is a single response to this question that suggests that the PrereqSupportPackage attribute can be used “to indicate that more than one package is required” as a prerequisite. This suggested that the answer to the prerequisite question just might be the PrereqSupportPackage attribute.
However, the response also contains the following rather disappointing information, which suggests that this might not be the solution. “A problem you might have is that pre-req packages are only installed if your BA fails to start.”


The idea that the PrereqSupportPackage attribute might not be the solution was reinforced by another question here on the WiX-Users mailing list titled PrereqSupportPackage only for .Net Prerequisites <http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PrereqSupportPackage-only-for-Net-Prerequisites-td7597503.html>.
The response to this question was “PrereqSupportPackage was pretty much designed for .NET prerequisites.”

Other responses I received here on the WiX-Users group essentially stated it is your BA and you are in control. This would have been more helpful if even one sentence was included to suggest how to accomplish this control.


The single response I received to my question on Stack Overflow was just a little more helpful. It contained the following paragraph.

After this you can do the various installation phases such as Detect, Plan and Apply. Showing your UI is simply using the .Show() method on a wpf page for example. Therefore you could delay showing the user your Ui till whenever you want in the installation.

I obtained the final piece of the puzzle by examining the source code for WiX to obtain more information on the PrereqSupportPackage attribute since this is the most promising lead I have thus far. Support for the PrereqSupportPackage attribute is found in the wixstdba project, specifically in the file *ext\BalExtension\wixstdba\WixStandardBootstrapperApplication.cpp*. The wixstdba project contains code that adds all packages with the PrereqSupportPackage attribute to a prerequisite package dictionary. The installers in the prerequisite package dictionary are installed if the m_fPrereq member variable is true. All other packages are installed if the m_fPrereq member variable is false. The m_fPrereq member variable is initialized using the value passed to the fPrereq parameter of the CreateBootstrapperApplication function.


This led me to investigate calls to the CreateBootstrapperApplication function. The wixstdba project provides two exported functions for creating the bootstrapper application, BootstrapperApplicationCreate and MbaPrereqBootstrapperApplicationCreate. The BootstrapperApplicationCreate function calls the CreateBootstrapperApplication function with the fPrereq parameter set to false and the MbaPrereqBootstrapperApplicationCreate
function calls the CreateBootstrapperApplication function with the fPrereq parameter set to true.


The next step was of course to find out when the functions MbaPrereqBootstrapperApplicationCreate and BootstrapperApplicationCreate are called. I found the answer in ext\BalExtension\mba\host \host.cpp. The MbaPrereqBootstrapperApplicationCreate function is only called if the GetAppDomain function fails. Thus when using the WixStandardBootstrapperApplication the statement that “pre-req packages are only installed if your BA fails to start” appears to be true.


However, when using a custom Managed Bootstrapper Application the wixstdba project is not used. Just because the wixstdba project only processes packages with the PrereqSupportPackage attribute set when called from the context of the MbaPrereqBootstrapperApplicationCreate function does not mean that a custom Managed Bootstrapper Application must do the same.


This is when the final solution occurred to me. Our custom Managed Bootstrapper Application could support the PrereqSupportPackage attribute.
All packages with this attribute set could be installed before the UI is displayed. All packages without the attribute set could be installed after the UI is displayed by the Show function.


Is this overall analysis correct? Does anyone have any suggestions to add?


Thanks. I am asking for additional information both so that I will be able to complete a task my employer has assigned me and in the hopes that others who encounter this issue will not have as much difficulty obtaining this information as I have.