Wix# Bootstrapper (Burn) integration notes

Oct 6, 2015 at 12:57 AM
Edited Feb 17, 2016 at 5:04 AM
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 opened for the discussion. So any feedback that can help to improve the Bootstrapper support will be appreciated.

Q: What exactly SilentBootstrapperApplication does?
A: First of all Burn doesn't implement (nor support) no-UI behavior. Burn allows building the bootstrtapper, which is controlled by either built-in native boostratpper 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 being installed on the target system before CustopmBA can be loaded. However Burn runtime is smart enough to handle such dependency and to bootstrapp .NET automatically if it is not detected at target system at runtime. Burn also delays loading the CaustoBA until .NET is fully installed.

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, which requires.NET to be installed before the CustomBA can be loaded. And indeed Burn shows its native UI while downloading and installing .NET. Displaying it is the only sensible behavior 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 comparing to the other deployment scenarios. MSI allows user 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 an UI doesn't exist. In fact Burn CustomBA is the only UI that can be displayed/controlled by user during the uninstall.

Q: Why setting DisplayInternalUI to true works for native MSI package UI but not for the EmbeddedUI?
A: Indeed it is a problem. Its cause is unclear and the initial assessment indicates that somehow Burn runtime doesn't detect the MSI EmbeddeUI in the MSI package.
It seems like currently there is no any workaround so the corresponding defect was logged on WiX Issue tracking system: http://wixtoolset.org/issues/4918/

Thus the only option for managed UI with bottstrapper is "Injection of a CLRDialog". Well 'the only option' until WiX made the fix available to public.
Feb 4, 2016 at 1:23 AM
Update
WiX team scheduled fixing issue 4918/4921 for WiX v4.0.