.NET Core support?

[sonicbhoc]

Is it possible to use Wix# in .NET Core? I installed the package but the namespace never shows up in Intellisense.

[oleg-shilo]

No, not really.
One of the strongest points of WixSharp is that its assembly can be used for CA as is. Though if it is a .NET Core assembly then CA is no longer possible as MSI/WiX runtime cannot host .NET Core.

[sonicbhoc]

Ah. Thank you. Off-hand, do you know if the same applies for custom bootstrapper UIs?

[oleg-shilo]

Yes it does.

Thus Burn bootstraps .NET installation so it runs first if it detects that target system has no .NET installed and only then loads CA .NET assembly and pops its UI. But if it is a .NET Core assembly then it will have difficulties loading it.

[schmitch]

@oleg-shilo shouldn't this be kept open? I mean we know that .net framework 4.x is a dead end, so at one point Wix# needs to use .net 5 or higher, so no matter the limitations it still might be a good idea to invest into it, instead of being stuck on an old technology?

[oleg-shilo]

Yeah, if WiX is ever upgraded to support .NET 5, WixSharp will support it too.

I am slightly skeptical of that. Particularly because MSIX is getting in the picture.
But there is no technical reasons for the WiX migration not to happen.

[schmitch]

well isn't WiX already on .net core? via .net standard. (well at least WIX 4.x): https://github.com/wixtoolset/Core/tree/master/src/WixToolset.Core

[oleg-shilo]

Yeah, via .net standard. Meaning that if you use .net core tools to compile .net standard assembly it can be used even now for current Wix+WixSharp.

Kinda no need for migration.

[oleg-shilo]

May be we need to have WixSharp recompiled for standard?

Just thinking out loud...

[schmitch]

the question than would be if the msbuild targets would be suitable 1:1 for the dotnet toolchain. I'm not sure if older msbuild rules would still work on newer tech, but maybe it would work.

Edit: But I think they are simple enough to just work.

[oleg-shilo]

I don't think they would. But we need to think about separating runtime hosting and authoring.

Authoring will need to be forked to support dotnet.exe compilation. Not a big deal as it still supports project build events. Though no *.targets. support. But... WixSharp's usecase for *.targets is something that I would not mind to loose.

If I do recompile WixSharo.dll for standard it will solve the portability problem even before .NET 5 arrives. But from the othe hand it would probably kill ManagedUI, which is WinForm so non-standard.

Anyway it's something to consider, experiment with....

Though one would question doing it before WiX 4 which is going to have some breaking changes anyway. So the rework on WixSharp is unavoidable.

Again, just some thoughts ...

[Basyras]

@oleg-shilo Can it be stated somewhere that WixSharp supports only .net Framework, just spend hour searching why I Visual studio could not find the WixSharp namespace in .net core project :)

[oleg-shilo]

That's unfortunate. NuGet package manager normally prints an error message about not finding compatible assets to install from the downloaded package. :(

Anyway, I agree it makes sense to state it in the main doc.
Done:

[Pinapala39]

i have an MSI Installer cs project which has wixsharp and wixsharp.bin for .net framework 4.8.
Migrating the project to .Net6 framework facing some issue in the wixsharp.

My question is that does , .Net 6 supports wixsharp/ wixsharp.bin nuget packages?

[oleg-shilo]

WixSharp is compiled for the target runtime that MSI/WiX supports so the project compiled assembly can be hosted at runtime (during msi installation).

Since MSI cannot host .NET Core assemblies, WixSharp project assembly needs to be compiled against MSI-supported runtime .NET Framework.