These are the key points of the investigation that was triggered by numerous questions regarding the Bootstrapper (Burn) support. Some of the points are just more detailed explanations of the architectural aspects of both WiX/Burn and Wix#. The content is presented in the form of Question/Answer. Thus it is in a way a short FAQ page that is open for discussion. So any feedback that can help to improve the Bootstrapper support will be appreciated.

It is important to note that Burn, despite being a mature solution exhibit a number of fundamental flaws. This results in the most requested scenario of bootstrapping with the product a user-chosen .NET setup being not supported adequately. WixSharp addresses this problem by supporting starting from v1.7.0 building fully native bootstrappers with NSIS compiler. The very first Q/A pair provides the details about this feature.

Q: Are they a way to automatic switches between custom/default UI. If dotNet 4.x is present/missing respectively.

A: No, it is impossible. The decision on UI hosting needs to be made at msi build time. This is the constraint of the MSI technology.

To solve this problem one must bootstrap the dependency setup (.NET setup file) into the deployment package. And this is exactly what all bootstrapping solutions do. Burn is one of them. While working very well, it has a few significant drawbacks.

The first one is the long-standing bug (http://wixtoolset.org/issues/4918/ and https://github.com/wixtoolset/issues/issues/4921/), which prevents displaying MSI own UI for the "EmbeddedUI" scenarios. It's not clear if this bug is ever going to be fixed. See "Why does setting DisplayInternalUI" question below for the work around suggestions.

The second one is the absence of any support for invisible bootstrapper UI. WixSharp Burn integration fixes this by providing a CustomBA with no window but such an installation is still not ideal. Burn may need at runtime to install .NET implicitly for its own UI and the user has no control over it. Controlling effectively .NET version of both (implicit and explicit) scenarios is close to impossible.

This is where NSIS Bootstrapper comes to the rescue. It allows producing clean native bootstrapper with no own UI and all embedded setups (with their respective UIs) simply being chained and executed one by one. Because NSIS is a native app there is no implicit installation. Thus the bootstrapper only installs the setups that the user included during the build.

Below is a simple setup that deploys the user-chosen .NET first if it is not detected on the system.

 static public void Main()
 {
     // ensure NSIS is installed
     var setup = new NsisBootstrapper();
     setup.DoNotPostVerifyPrerequisite = true;
     setup.PrerequisiteFile = "NDP451-KB2859818-Web.exe"; // bootstrapped .NET 4.51 setup
     setup.PrimaryFile = "MainProduct.msi";
     setup.OutputFile = "MainProduct.exe";
     setup.PrerequisiteRegKeyValue = @"HKLM:SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs\.NETFramework,Version=v4.5:";

     setup.Build();
 }

Q: What exactly SilentBootstrapperApplication does?

A: First of all, Burn doesn't implement (nor support) no-UI behaviour. Burn allows building the bootstrtapper, which is controlled by either built-in native bootstrapper application (default UI) or by the custom managed bootstrapper application CustomBA. Wix# facilitates a building CustomBA. It also provides a pre-built CustomBA that does not have any window displayed at runtime:

bootstrapper.Application = new SilentBootstrapperApplication();

Thus SilentBootstrapperApplication (SilentBA) is a typical bootstrapper application, which behaves as a typical BA except it doesn't show any UI.

Q: Can CustomBA (e.g. SilentBA) be used to deploy a package on the target system where .NET is not present?

A: Yes it can. Any CustomBA is a managed application thus it naturally establishes the dependency on the corresponding version of .NET on the target system, before CustopmBA can be loaded. Burn runtime is smart enough to handle such dependency and to bootstrap .NET automatically if it is not detected at the target system at runtime. Burn also delays loading the CaustoBA until .NET is fully installed.

Q: Are they a way to automatic switches between custom/default UI (msi UI). If dotNet 4.x is present/missing respectively.

Q: Why bootstrepper shows Burn dialog for a bootstrapped .NET installation even if SilentBA is set as a bootstrapper application?

A: Burn doesn't understand that the CustomBA (e.g. SilentBA) is going to show no UI. For Burn it is just another managed application (CustomBA), which requires.NET to be installed before this CustomBA can be loaded. And indeed Burn shows its native UI while downloading and installing .NET. Displaying it is the only sensible behaviour in this case, as the installation can take up to a few minutes and leaving the user without any visual feedback would create a really questionable User Experience. On top of this Burn must collect user input for accepting the .NET distribution licence. Thus showing a native UI is a must. However, from the moment the .NET installation is complete Burn immediately closes the native UI and loads the user-provided CustomBA.

Q: Why uninstall UI of the bootstrapper MSI package is never displayed even if DisplayInternalUI is set to true?

A: The uninstalling is different compared to the other deployment scenarios. MSI allows users to specify custom Install, Repair and Change UI. However during uninstall MSI always take charge and displays no UI (or its own very minimalistic quick disappearing messagebox style dialog). Thus Burn cannot possibly show uninstall UI as such a UI doesn't exist. In fact, Burn CustomBA is the only UI that can be displayed/controlled by the user during the uninstall.

Q: Why does setting DisplayInternalUI to true work for the native MSI package UI but not for the EmbeddedUI?

A: Indeed it is a problem. Various WiX user complains indicate that somehow Burn runtime doesn't detect the MSI EmbeddeUI in the MSI package. It seems like currently there is no workaround so the corresponding defect was logged and acknowledged by the WiX team on their issue tracking system:

• http://wixtoolset.org/issues/4918/
• https://github.com/wixtoolset/issues/issues/4921/

Thus the only options for managed UI with bootstrapper are one of these approaches:

• Use NSIS bootstrapper which is immune to this problem (see the sample)
• Instead of bundling msi directly you can wrap it in the executable and then bundle the executable with the appropriate detection algorithm defined. (see sample)

Well, 'the only options' until WiX makes the fix available to the public.