Feature request: first-class support for treating sources as scripts, with wixsharp as a CLI interpreter

[fredemmott]

It seems that while WixSharp is built on top of CS-Script, the primary intended way to operate it is via Visual Studio templates that build the full MSI.

While there are some notes about copying cscs.exe and the WixSharp DLLs, and a sample of building without visual studio, it seems like this is something you discourage at the moment

If you were to support something like this:

dotnet tool run wixsharp installer.cs [argsForMyMainFunctionHere...]

... that would be much easier to integrate with projects that use other build systems (e.g. cmake for portable C++, Cargo for rust), especially on disposable CI workers.

I'm able to meet my needs with the template and reading parameters from environment variables - this request would just have made integration much simpler.

[fredemmott]

I've found a better approach than environment variables:

• use the .Net core template
• remove the post-build task that generates the MSI
• dotnet run YOUR_ARGUMENTS_HERE

For example: https://gist.github.com/fredemmott/1047871f102b411c9acf566499c48f84

[oleg-shilo]

You are correct, in most cases.

WixSharp is built on top of CS-Script,...

Not exactly. WixSharp has no connection to CS-Script except that both are created by the same person (me). Before .NETCore become public CS-Script provided a simple way of building WixSharp authored msi from CLI. And considering the fact that CS-Script is available via Chiloclate, .NET Tools and WinGet it was easy enough to integrate with and CI. But there is a zero dependency on CS-Script. Though today, with the appearance of .NET Core family the need for a C# interpreter (cscs.exe) is no longer there.

. that would be much easier to integrate with projects

The intended way of building msi with WixSharp is to create the VS project and then integrate it with CI as any other VS project.
IE

dotnet build

And this is exactly the reason why you should not remove the post-build event. It is the very routine that executes the build script:

I hope it clarifies

[fredemmott]

And this is exactly the reason why you should not remove the post-build event. It is the very routine that executes the build script:

this is exactly the reason I removed it: separating the build and run steps allows me to execute it with differing arguments without modifying the project every time.

The post build task makes this approach incompatible with mandatory arguments.

[fredemmott]

Most projects I see that build 1 component then use this to build a second do this by having multiple build targets with a dependency, rather than a post-build task; that approach would keep the “just build it to get msi” standard behavior, but add more flexibility

[fredemmott]

The intended way of building msi with WixSharp is to create the VS project and then integrate it with CI as any other VS project.
IE

Sorry for splitting my replies up; anyway, to expand on this:

Most build systems work on the idea of producing a set of outputs from a set of inputs, and repeating this action when the set of inputs change - either when there are more inputs, or when an input has been modified.

On this model, wixsharp has two steps:

1. create an executable from the .cs which produces a .exe
2. use the .exe and to produce a .msi

With the usual templates, 'other inputs' are not defined as inputs in the build system - not even in msbuild - so the build can't reliably detect when the msi is still and needs rebuilding.

Keeping the two steps separate allows using the definition of all inputs - the wixsharp .cs and the files that are actually going to be installed - from the project's primary build system to be used to compute the staleness and need to rebuild.

[oleg-shilo]

I actually agree with your reasoning. It was what I implemented initially.

Initially, WixSharp integration was done through *.targets file, which simply invoked the exe at the and of the build. The same way as the event does. Though users often wanted manually remove the reference to the targets file from the project definition. It also was difficult to implement reliable "remove package" scenario.

As an alternative, I tried to encourage users to simply build the exe and then execute it. Exactly your two steps approach. Noone liked it, even though it is the easiest way to debug your build.

So I gave up and implemented the simplest possible approach.