add support for pre/post inst/un scripts

[mh-cbon]

like rpm/debian package does,

it would be a good thing to provide native support
for those scripts during install/uninstall operations of the package.

TBD

In the manifest, 4 new fields should be provided.
They target some cmd (powershell?) files.
When the package is built, somehow they are integrated in the result so that when the package is run, they are executed appropriately.

TODO

• Update manifest to add those 4 fields
• Include those files to the produced msi package
• Update wix flow files to detect, declare and run those scripts as expected

FYI

• http://yentran.org/blog/2013/09/26/wix-batch-file/
• http://stackoverflow.com/questions/170144/how-to-run-a-script-in-wix-with-a-custom-action-simplest-possible-example
• http://stackoverflow.com/questions/2313545/execute-command-line-in-wix-script
• http://wixtoolset.org/documentation/manual/v3/xsd/wix/customaction.html
• https://github.com/damienbod/WiXPowerShellExample
• https://damienbod.com/2013/09/01/wix-installer-with-powershell-scripts/

[2opremio]

I really need this feature. How can I help?

As a workaround, what's the best way to patch the wix templates and hardcode the commands?

[mh-cbon]

As a workaround, what's the best way to patch the wix templates and hardcode the commands?

I guess you refer the hardcoded commands as the new script
to execute during the installation of the msi.

I d simply add a new field to the manifest
to declare the path to the bat and its option.

scripts: [
"path/file.bat": { ...options... },
]

According to this example the CustomAction element is suitable

I d add those new nodes under the Product Node

So the location of the bat files is not following a convention, the user decides.

Also the definition of the moment of execution of the script is not using the same logic as linux,

Name	Type	Description
Execute	Enumeration	This attribute indicates the scheduling of the custom action. This attribute's value must be one of the following:

commit
Indicates that the custom action will run after successful completion of the installation script (at the end of the installation).
deferred
Indicates that the custom action runs in-script (possibly with elevated privileges).
firstSequence
Indicates that the custom action will only run in the first sequence that runs it.
immediate
Indicates that the custom action will run during normal processing time with user privileges. This is the default.
oncePerProcess
Indicates that the custom action will only run in the first sequence that runs it in the same process.
rollback
Indicates that a custom action will run in the rollback sequence when a failure occurs during installation, usually to undo changes made by a deferred custom action.
secondSequence
Indicates that a custom action should be run a second time if it was previously run in an earlier sequence.

That s all i guess.

[2opremio]

Fantastic, thanks!