Using PublishAot instead of SfxCA for custom actions

[klokkenman1]

Hey,

I've been working on a project that involves upgrading .net framework projects too .net 8 and ran into the same issue described in #1357

Reading #802 it seems that it was decided to only support .net framework because only by doing this could wixsharp easily support Custom Actions. My assumption is that this is because it uses the MakeSfxCA.exe underwater is that correct?

However after more tinkering and searching i did find a person that got a .net 7 library working as a custom action using PublishAot

Native Aot does certainly have its limitations but would this not be an avenue for WixSharp to start supporting newer .net versions?

If there is any update I missed that allows WixSharp to build with newer .net I would love to hear it!

[oleg-shilo]

If there is any update I missed

Sorry to say but no you did not miss anything. Until WiX team provide the solution for .NETCore support WixSharp cannot do anything about it.

Though AOT seems like an interesting experimental approach. Even though I am not convinced of the business value.
I will have a look and it is straightforward will see if I can release it as an experimental feature.

[oleg-shilo]

I can confirm it now. Yes, it is possible. I will add support in the next release. However, it is only going to help with raw CA.
ManagedProject cannot be done so it's kinda cripled.

[oleg-shilo]

Done:
https://github.com/oleg-shilo/wixsharp/blob/wix-v4-master/Source/src/WixSharp.Samples/Wix%23%20Samples/DTF%20(NetCore%20CA)/setup.cs

[klokkenman1]

Hey Oleg,

Wow you work fast, awesome work!

However, it is only going to help with raw CA. ManagedProject cannot be done so it's kinda cripled.

Could you explain some more about this?

Looking at your example also gave me a different insight, leaving the wixsharp project .net framework always made it so the compiler complained about it being unable to reference a project of .Net 8 (e.g. not a custom action but the software I want installed) however in your example you don't seem to use a project reference and I could apply this to non custom actions as well. Is this advised or just a workaround for the same issue?

[oleg-shilo]

Let's review it...
It may help us to understand what is feasible.

.NET Core support

Current state

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 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 (currently deliberately disabled).

AOT compilation offers an interesting opportunity as the compiled assembly effectively becomes a native dll. Thus some scenarios can be scenario implemented providing the assemblies are AOT-ed by WixSharp before the msi compilation.

...	Functionality	Host	Runtime	Comment
1	CA	MSI	Native, AOT-asm	supported
2	Managed CA (DTF)	WiX	.NET Framework	not needed any more
3	Managed Project Events	WixSharp	AOT-asm	Possible if not too much dependencies
4	Custom BA (Burn)	WiX	.NET Framework	has to stay .NET Framework
5	Embedded UI	WiX	.NET Framework	has to stay .NET Framework
6	MSI builder	WixSharp	AOT-asm	supported

I have already got scenarios 1 and 6 working.

Remaining scenarios:
3. It is likely possible unless it is too difficult to keep it together.
4. Scenario 4 is completely out as there is no chance to influence WiX team. They are most likely going (or not) to support it eventually. However, there is no way to impact the schedule of the delivery of this functionality. I feel like the WiX team is underresourced to do it quickly.
5. The same as above.
Though there is a small chance that I will be able to by pass WiX runtime and embed AOT-asm directly in msi. Some heavy investigation is required.

I am currently trying to POC scenario #3 if it works then I will release a NET8 port of WixSharp. I really dislike the idea of maintaining 3 streams of product WiX3, WiX4 and WiX4-NETCore.
But I feel otherwise we will have to wait for NETCore integration next 5-7 years.

[klokkenman1]

Once again awesome work!

This is a super clear overview of the external functionality that the installer can provide.
As much as I do hope this works out and allows us to use WixSharp with newer .NET I definitely understand the dilemma of having to support another product.

In case it does not work out I kinda wanna come back on the project reference thing I mentioned in the previous comment. Because as much as external functionality is important I do think the core functionality of "Installing files" in the form of a build project. Has more support in Wix than it has in WixSharp. e.g. I can add a .net8 application as project reference to a Wix project and build an installer with it.

If I wouldn't be able to upgrade my installer code to a new framework then I feel like that's not the end of the world. But if the installer is preventing me from also upgrading my project im trying to install that's a bigger annoyance.

Even if AoT doesn't work out I feel like there should be a way to cleanly allow for the core functionality of installing files from a newer .net project do you feel the same way?

[oleg-shilo]

What you are proposing is quite feasible. I will treat it as a proposal and will see how best to implement it.

Though, while I accept your motivation as a WixSharp user, through the history of WixSharp I am trying to move away from MSI/WiX philosophy when your deployment solution is primary and everything else only serves it. This leads to questionable concepts, such as the need for a dedicated msi developer, MSI/WiX technology being its own discipline or even having WiX project referencing application project(s).

As a developer you want to build an MSI because you have the product, not vice versa. Sorry for referencing my interview but this will give you more insight into this approach: https://www.infoq.com/articles/WixSharp/

Thus for me Product is primary and the deployment is secondary. Thus You build your product, you aggregate it for further testing and release preparation. Every CI has this artifacts aggregation step. And then you simply build your msi with a single direct artifact referencing, not a source code/project referencing line.

var project = new Project("My App",
                  new Dir(@"%ProgramFiles%\My Company\My App",
                      new AllFiles(@"\\BuildServer\LatestRelease\*.*")));

The code above is an ideal deployment authoring definition. BTW I can even develop and provide an XCopyProject and it will not require me to change the deployment definition.

MS itself has abandoned MSI evolution and invested in fundamental alternatives from ClickOnce to MSIX and containers. Even though MSI will always be supported and even somewhat integrated with alternative deployment approaches.

Anyway, I will see what ven be done for VS project referencing.

[klokkenman1]

I fully agree that the deployment is there to support the product and not the other way around.

Our (simplified) current situation is that we have one solution file with both the product and the deployment in it an splitsing this and adding an extra build step seems like a fine solution to my problem. However, I do think it's very powerful and assists in your vision of not needing separate deployment developers that everything is in a single solution.

For example having everything in one solution is never going to result in a developer never having seen the WixSharp projects. Because: "Its is only a solution that barely changes" Or "That solution just does its thing on the build server"

But that's just my two cents.

Thank you so much for your time and effort! We are definitely able to move forward, and I'll keep my eyes peeled for any changes that might come from this.

[oleg-shilo]

All good. I am focusing now on .NETCore support.

But when I am done I will get in touch with you to understand the exact requirement you have in mind for auto-processing project references. Then it will be clear how to handle this challenge.

Cheers
Oleg

[oleg-shilo]

I published the pre-release nuget package for .NET 8 project:
https://github.com/oleg-shilo/wixsharp/blob/wix-v4-master/Source/src/NET-Core

[klokkenman1]

I'll check it out soon, very cool progress!

[oleg-shilo]

And now I can confirm that ManagedProject events are also possible. Even though reflection under AOT compiled runtime is a nightmare.

The code below already works in the POC branch:

using System.Reflection;
using WixSharp;
using WixToolset.Dtf.WindowsInstaller;
using File = WixSharp.File;

var project =
    new ManagedProject("My Product",
        new Dir(@"%ProgramFiles%\My Company\My Product",
            new File("program.cs")));

project.BeforeInstall += e =>
    Native.MessageBox("Before Instrall", "WixSharp - .NET8");

project.AfterInstall += e =>
    Native.MessageBox("After Instrall", "WixSharp - .NET8");

project.Load += (e) =>
    Native.MessageBox("OnLoad", "WixSharp - .NET8");

project.UI = WUI.WixUI_ProgressOnly;

project.BuildMsi();

Now it's time to bring it all together.