You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 14, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: src/Docusaurus/docs/fivefour/oopbas.md
+22-20Lines changed: 22 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,8 +1,10 @@
1
1
# Out-of-process bootstrapper applications in WiX v5
2
2
3
-
In WiX v5, bootstrapper applications are separate processes and no longer hosted by the Burn process. The motivation for this change can be found in [#7916](https://github.com/wixtoolset/issues/issues/7916). This is obviously a significant breaking change so it was also taken as an opportunity to improve several .nupkg package names as described in [#8020](https://github.com/wixtoolset/issues/issues/8020).
3
+
In WiX v5, Burn launches bootstrapper applications as separate processes rather than loading them as DLLs inside the Burn process. If using the WiX Standard Bootstrapper Application or WiX Internal UI Bootstrapper Application, the move to out-of-process bootstrapper applications is abstracted away and should not introduce any breaking changes or required authoring changes.
4
4
5
-
If using the WiX Standard Bootstrapper Application or WiX Internal UI Bootstrapper Application, the move to out-of-process bootstrapper applications is abstracted away and should not introduce any breaking changes. The rest of this document details changes required to custom bootstrapper applications.
5
+
The rest of this document details changes required to update custom bootstrapper applications to WiX v5.
6
+
7
+
The motivation for this change can be found in [#7916](https://github.com/wixtoolset/issues/issues/7916). This is obviously a significant breaking change so it was also taken as an opportunity to improve several .nupkg package names as described in [#8020](https://github.com/wixtoolset/issues/issues/8020).
6
8
7
9
First, the custom bootstrapper application project needs to change from DLL to EXE.
8
10
@@ -21,7 +23,7 @@ exampleba.csproj
21
23
22
24
and reference the `WixToolset.BootstrapperApplicationApi` NuGet package (this one package replaces both the `WixToolset.BalUtil` and `WixToolset.Mba.Core` packages).
23
25
24
-
As an executable, the boostrapper application needs a `main` function. Bootstrapper application main functions should be minimal to connect to the parent burn process as quickly as possible. For example,
26
+
As an executable, the bootstrapper application needs a `main` function. Bootstrapper application main functions should be minimal to connect to the parent Burn process as quickly as possible. For example,
25
27
26
28
```cpp
27
29
// exampleba.cpp
@@ -49,41 +51,41 @@ or
49
51
50
52
```cs
51
53
// example.cs
52
-
using WixToolset.BootstrapperApplicationApi;
54
+
using WixToolset.BootstrapperApplicationApi;
53
55
54
-
internal class Program
56
+
internal class Program
57
+
{
58
+
private static int Main()
55
59
{
56
-
private static int Main()
57
-
{
58
-
var application = new ExampleBoostrapperApplication();
60
+
var application = new ExampleBootstrapperApplication();
59
61
60
-
ManagedBootstrapperApplication.Run(application);
62
+
ManagedBootstrapperApplication.Run(application);
61
63
62
-
return 0;
63
-
}
64
+
return 0;
64
65
}
66
+
}
65
67
```
66
68
67
-
Notice that the bootstrapper engine and command objects are no longer passed to the creation of the bootstrapper application. Those values are not available until the application has been connected to the parent burn process in `Run()`. Therefore, there is a new `OnCreate()` bootstrapper application callback that provides both the bootstrapper engine and command objects. To keep the API balanced an `OnDestroy()` callback was also added.
69
+
Notice that the bootstrapper engine and command objects are no longer passed to the creation of the bootstrapper application. Those values are not available until the application has been connected to the parent Burn process in `BootstrapperApplicationRun` or `ManagedBootstrapperApplication.Run`. Therefore, there is a new `OnCreate` bootstrapper application callback that provides both the bootstrapper engine and command objects. To keep the API balanced, an `OnDestroy` callback was also added.
68
70
69
71
At this point, the bootstrapper application API is fairly compatible with only a few additional details to keep in mind.
70
72
71
73
* Managed BootstrapperApplications no longer support changing "run async". BA's now always run their UI in a separate thread.
72
-
*`BootstrapperApplicationFactory` concept no longer used. Remove all classes related to it. Create the BootstrapperApplication in the `main` function as shown above.
*`CBalBaseBootstrapperApplication` deprecated, use `CBootstrapperApplicationBase` instead.
74
+
*The `BootstrapperApplicationFactory` concept no longer used. Remove all classes related to it. Create the BootstrapperApplication in the `main` function as shown above.
*`CBalBaseBootstrapperApplication`was deprecated, use `CBootstrapperApplicationBase` instead.
75
77
76
78
To take advantage of the breaking change, we took the opportunity to improve the names of many NuGet packages related to custom bootstrapper applications:
77
79
78
-
*`WixToolset.BalUtil` - renamed to `WixToolset.BootstrapperApplicationApi` to provide the native headers and libraries to communicate Burn. Also, split out the `WixToolset.WixStandardBootstrapperApplicationFunctionApi` for WiX Standard Bootstrapper Application functions API.
79
-
*`WixToolset.Mba.Core` - merged the managed headers into the `WixToolset.BootstrapperApplicationApi` so there is a single package for custom bootstrapper applications.
80
+
*`WixToolset.BalUtil` - renamed to `WixToolset.BootstrapperApplicationApi` to provide the native headers and libraries to communicate with Burn. Also, split out the `WixToolset.WixStandardBootstrapperApplicationFunctionApi` for WixStdBA BAFunctions API.
81
+
*`WixToolset.Mba.Core` - merged the managed libraries into the `WixToolset.BootstrapperApplicationApi` so there is a single package for custom bootstrapper applications.
80
82
*`WixToolset.BextUtil` - renamed to `WixToolset.BootstrapperExtensionApi`.
81
-
*`WixToolset.Bal.wixext` - renamed to `WixToolset.BootstrapperApplications.wixext` but also kept`WixToolset.Bal.wixext` for backwards compatibility.
82
-
*`WixToolset.Dnc.HostGenerator` - no longer relevant in WiX v5 and not available.
83
+
*`WixToolset.Bal.wixext` - renamed to `WixToolset.BootstrapperApplications.wixext` but also kept`WixToolset.Bal.wixext` for backwards compatibility.
84
+
*`WixToolset.Dnc.HostGenerator` - no longer needed in WiX v5.
83
85
84
86
85
87
:::tip
86
-
Set a **SYSTEM** environment variable named `WixDebugBootstrapperApplications` to `true` to get a prompt to debug all boostrapper applications. Set a **SYSTEM** environment variable named `WixDebugBootstrapperApplication` to the file name of the bootstrapper application executable to get a prompt to debug that bootstrapper application.
88
+
Set a **system** environment variable named `WixDebugBootstrapperApplications` to `true` to get a prompt to debug _all_ bootstrapper applications. Set a **system** environment variable named `WixDebugBootstrapperApplication` to the file name of the bootstrapper application executable to get a prompt to debug that bootstrapper application.
0 commit comments