BootstrapperApplication Processes

[robmen]

User story

• As a setup developer, I can develop a custom BoostrapperApplication in any programming language.

Proposal

In WiX v3 and v4, BoostrapperApplications are hosted by the Burn process. Originally, this host was the initially launched Burn process that extracted and started the BootstrapperApplication as quickly as possible. With the creation of the clean room, the Bootstrapper application was extracted by the initial Burn process but hosted in a separately launched Burn process. In all cases, burn.exe is the host process for the BoostrapperApplication.

Burn as the process host means that adapters must be provided to host BootstrapperApplications written in languages that do not compile to a Windows native DLL. The most popular case is managed code, and the WiX Toolset provides adapters for both .NET Framework and (in WiX v4) .NET Core. However, as .NET continues to develop, it is clear that in-proc hosting of .NET Core is not a priority. Most importantly, advancements in AOT and single file deployment in .NET 8 broke WiX v4 hosting of .NET Core in Burn when using those features. This would not be a problem if burn.exe was not the host and if BootstrapperApplication functionality was provided as a library instead.

Also, due to the changes to support the clean-room, BootstrapperApplications are always run by starting another instance of burn.exe; there is no advantage of trying to use Burn as a host process. Therefore, we will change BootstrapperApplications to be processes that communicate with the Burn engine out of proc. The WiX Toolset will continue to provide implementations for native DLLs and managed code via a library that implements the out-of-proc communication channel.

Considerations

• In the future, we might consider a more friendly wire protocol to replace the bespoke struct transmission from the original Burn design.