.NET Core support
This page is largely based on the discussions around this topic in the repository discussion boards. Particularly #1456.
Note that .NET Core support is currently partial and confined within the special codebase stream WixSharp.Core. However it has all the usual developer experience implemented: .NET Packages, VS Templates, Samples.
To understand the limitations of WixSharp.Core one needs to understand the nature of the challenges coming from the fact that WiX4 (as of Mar 2024) has no support for .NET Core runtime. The functionality presented on this page is WixSharp-specific advance in the MSI authoring process with the assistance of .NET Core family of the framework.
This is how external functionality can be embedded in MSI/WiX currently (WiX4):
| ... | Functionality | Host | Runtime | Comment |
|---|---|---|---|---|
| 1 | CA | MSI | Native | native dll |
| 2 | Managed CA (DTF) | WiX | .NET Framework | assembly wrapped into native dll proxy |
| 3 | Managed Project Events | WixSharp | .NET Framework | Managed CA defined as CLR event |
| 4 | Custom BA (Burn) | WiX | .NET Framework | |
| 5 | Embedded UI | WiX | .NET Framework | Assembly wrapped into native dll interop |
| 6 | MSI builder | WixSharp | .NET Framework | Assembly built by WixSharp VS project |
In MS/WiX vision all 1-6 cases are implemented as individual modules/workflows. This leads to a very fragmented deployment definition implemented as multiple projects define the functionality in different programming languages.
WixSharp takes a different and rather elegant approach. Everything can be defined as a single assembly with a very minimalistic user code.
This approach is possible because all the assemblies of MSI/WiX workflows are of the same runtime type. Thus WixSharp can combine them in a single assembly. But if we try to convert it in .NET Core then it becomes tricky.
None of the scenarios from the table above support .NET Core compiled assemblies except 6 MSI builder (deliberately disabled in WixSharp .NET Framework edition).
There is an interesting opportunity associated with the concept of . NET Core Ahead-Of-Time compilation (AOT). AOT compilation offers the possibility of compiling an assembly into a native image, effectively such an assembly becomes a pure native dll. Thus some scenarios can be implemented providing the assemblies are AOT-ed by WixSharp before the msi compilation.
Thus starting from version 2.1.2 WixSharp offers limited support for .NET Core. The features below are available via NuGet and Visual Studio Templates: https://www.nuget.org/packages/WixSharp.Msi.Core https://www.nuget.org/packages/WixSharp.Core https://marketplace.visualstudio.com/items?itemName=OlegShilo.WixSharpProjectTemplates
The table below shows the supported features that are possible to utilize in the .NET Core (.NET 8) Visual Studio projects.
| ... | Functionality | Host | Runtime | Comment |
|---|---|---|---|---|
| 1 | CA | MSI | Native, AOT-asm | supported |
| 2 | not needed any more; fully covered by case #1
|
|||
| 3 | Managed Project Events | WixSharp | AOT-asm | supported |
| 4 | Custom BA (Burn) | WiX | .NET Framework | has to stay .NET Framework |
| 5 | Embedded UI | WiX | AOT-asm + .NET Framework | supported (hybrid solution) |
| 6 | MSI builder | WixSharp | AOT-asm | supported |
Notes: Scenario 4 is supported as a hybrid solution when the msi is built with .NET Core (currently supported) and the UI is built as a .NET Framework assembly and simply referenced from the msi as an external EmbeddedUI assembly. See this sample.
As for scenario 5, there is very little chance of getting WiX team to support Custom BA hosting of .NET Core built assemblies. They are most likely going (or not) to support it eventually. However, it's problematic to influence the schedule of the delivery of this functionality. However, it is possible to have the hybrid approach when the msi is built with .NET Core (currently supported) and the UI is built as a .NET Framework assembly and simply referenced from the msi as an external EmbeddedUI assembly.
If the demand exists there will be a possibility to implement a hybrid approach described in scenario 4 for the bootstrapper as well.
Create your project from the appropriate Visual Studio template:
That's it. You can compile and build it.
Remember, you should minimize the use (if use it at all) of any UI like WinForm message boxes as it will dramatically increase the size of your msi due to the inclusion of System.Windows.Forms namespace in your AOT-compiled assembly.