I have custom action scheduled after InstallFinalize. When I run a setup, and it fails, I noticed that I get error screen that setup failed and no changes were done to my computer, but if I run setup again, it has options to repair, change or remove. I assume that it's because the rollback event isn't triggered. How can I make it happen?
The InstallFinalize action is when the installation transaction is committed to the machine. Anything that happens after that point (or before InstallInitialize) happen outside the transaction. That means they cannot be rolled back.
Instead, you'll need to schedule your custom action sometime after InstallInitialize and before InstallFinalize in order for it to error and cause rollback. Additionally, a custom action that modifies machine state should be deferred. This topic in the MSI SDK is a good place to start and then read topics around it.
If you'd like to see examples of the way to write custom actions, I'd recommend looking at some examples in the WiX toolset in src\ca\wixca\dll. Lots of different kinds of custom actions doing things in a way I hope is "correct" according to the MSI SDK.
Related
I have created a Wix installer having multiple functionalities like deploying a service to Tomcat, Add and update config file of service at tomcat server and some other, Creating Web application at IIS, Creating MongoDB etc.
So to do some update config kind of task I have written custom actions with deferred execution, sometimes due to some reason custom action get failed and it causes to Rollback and sometimes this rollback leaves some footprints like service at Tomcat or other configuration files or may want to remove Mongo DB etc.
SO here I want to remove left footprints using a custom action just after rollback happened.
I have added a custom action Execute="rollback" and calling it Before="Installfinalize", But it's just calling before rollback happened.
Is there any way to deal smartly with such kind of situation?
Rollback custom actions only execute after a failure has occurred, and only the subset that were scheduled before the error. Assuming you need elevated privileges, they are your only clean option, so I would start with verifying the order of your actions' scheduling.
There's one more place you can try to run an action after rollback occurs: as the end of the Install UI Sequence. When an error occurs in an installation that's showing full UI, it will then run UI sequence entry msiDoActionStatusFailure (-3). Typically this shows a dialog box explaining that the installation (or uninstallation) failed. And it's hard to do more, as properties do not flow back from the execute sequence to the UI sequence.
In theory you can schedule any action at that entry in order to do something first. However, this action will run with the same privileges as the UI (typically limited), and will only run when the UI is shown. So this probably will not help your scenario. (Also, unless you're careful, you'll mess up the expected UI experience if you fail to invoke the dialog box it would otherwise show.)
I am looking for the exact list of operations that are executed during an upgrade of an msi file, in terms of Wix standard actions (StartServices, RemoveFiles etc.).
I am asking because I want to insert to my wxs file some custom actions, and I need to know how to schedule them.
Thanks in advance,
Eitan
This is a very detailed discussion. In general realize that during any given transaction (install, uninstall, repair, maintenance (feature install/uninstall), upgrade (major and minor) that any given component could be getting installed, reinstalled or removed. Depending on the nature of the component, operations could be scheduled (immeadiate) and executed (deferred). This means that one or more of the standard actions you mentioned could be doing something. In the case of a rollback they could be undoing something also.
I would start here:
Installation Phases and In-Script Execution Options for Custom Actions in Windows Installer
Zataoca: Custom actions are (generally) an admission of failure.
Zataoca: Custom actions should be data driven
Data Driven Managed Custom Actions made easy with DTF
Beam Me Up: Using JSON to serialize CustomActionData
It's a lot to cover but if you want to do it properly you want to write one or more custom tables to describe what needs to be done and have a join to the Component table to drive "when" it happens. The custom actions then implement "how" it happens. A custom action to query the tables and evaluate the component states to pass data to multiple custom actions to perform the work, rollback the work and dispose (commit) of any artifacts that were saved off to support rollback or weren't safe to perform until the very end of the install (assuming rollback wasn't disabled).
I'm new to wix and have a very important question
My installer should ignore the return status- meaning it should complete successfully but I do need to display to the user a warning with the return status in case it did not succeed.
or even better check the code and analyze accordingly
how do I do it with wix installer?
WiX generates MSI files, and when they run you don't have any control over what the return value will be. You also may be unaware that it's a transactional install. If it works it works and everything is fine, if it fails then it will rollback and restore the system to its starting point. This behavior can be screwed up to a certain extent if you add your own code (in a custom action) to change the system and then don't write rollback code to undo what you did, but there is no partial install that you need to warn anyone about.
In your Wix project file, you could insert the Warning task
at the appropriate place.
I want to add customized dialog box for uninstallation of my application.
I have also tried the following:
<InstallUISequence>
<Show Dialog="RemoveDlg" OnExit="success">REMOVE="ALL"</Show>
</InstallUISequence>
Is it possible or not in wix? Can anyone help me out with this?
While you can certainly author dialogs that are specific to product removal, uninstallations started from the remove button in Add or Remove Programs (now Programs and Features) are run without the UI sequence, and thus will not show these dialogs. One common alternative is to set the ARPNOREMOVE property which then requires the end user to click Modify instead of Remove. The modify button starts maintenance, which does show your UI.
Unless the data in %appdata%\product\ can cause problems for a re-installation of the application I would recommend leaving it in place on uninstall. Whatever you install in this folder is considered user data, and should not be automatically removed by default - and often not as an option either. Many companies apply custom permissioning on the userprofile folders. Messing around in there could cause your MSI to hickup seriously - particularly on terminal servers by triggering self-repair (which is generally not allowed on TS).
Keep in mind that the same installation sequence is used for install, uninstall and patching. If you use major upgrade patches that essentially uninstall and reinstall the product you could end up deleting the user data and reinstalling it for every installation. If this is acceptable, the data you deal with is not user data, and is hence located in the wrong place on disk.
If you run a delete operation towards the end of the uninstall via a custom action that checks exit code, you could trigger rollback of the uninstall, essentially causing the product to be reinstalled and be impossible to uninstall! Rare, but it happens. If the custom action is run after InstallFinalize and hence outside the MSI install sequence your setup could return an uninstall error code and leave your product broken and the uninstall incomplete or your product partially unregistered.
In short I wouldn't mess around with this. If you have insistent customers I wouldn't mess with a dialog if I could help it. I would add a PUBLIC property to control whether a custom action is run immediately prior to InstallFinalize. Flush any error return codes and write information into the MSI log instead. Then users could uninstall user data by specifying the property on the command line or hard code it in the Property table.
If you have to have a GUI you can use the same property to set from a custom dialog to control whether deletion is done or not. Remember to condition the display of the dialog with care. I.E don't show it during patching operations.
I want to add customized dialog box for uninstallation of my application.
I have also tried the following:
<InstallUISequence>
<Show Dialog="RemoveDlg" OnExit="success">REMOVE="ALL"</Show>
</InstallUISequence>
Is it possible or not in wix? Can anyone help me out with this?
While you can certainly author dialogs that are specific to product removal, uninstallations started from the remove button in Add or Remove Programs (now Programs and Features) are run without the UI sequence, and thus will not show these dialogs. One common alternative is to set the ARPNOREMOVE property which then requires the end user to click Modify instead of Remove. The modify button starts maintenance, which does show your UI.
Unless the data in %appdata%\product\ can cause problems for a re-installation of the application I would recommend leaving it in place on uninstall. Whatever you install in this folder is considered user data, and should not be automatically removed by default - and often not as an option either. Many companies apply custom permissioning on the userprofile folders. Messing around in there could cause your MSI to hickup seriously - particularly on terminal servers by triggering self-repair (which is generally not allowed on TS).
Keep in mind that the same installation sequence is used for install, uninstall and patching. If you use major upgrade patches that essentially uninstall and reinstall the product you could end up deleting the user data and reinstalling it for every installation. If this is acceptable, the data you deal with is not user data, and is hence located in the wrong place on disk.
If you run a delete operation towards the end of the uninstall via a custom action that checks exit code, you could trigger rollback of the uninstall, essentially causing the product to be reinstalled and be impossible to uninstall! Rare, but it happens. If the custom action is run after InstallFinalize and hence outside the MSI install sequence your setup could return an uninstall error code and leave your product broken and the uninstall incomplete or your product partially unregistered.
In short I wouldn't mess around with this. If you have insistent customers I wouldn't mess with a dialog if I could help it. I would add a PUBLIC property to control whether a custom action is run immediately prior to InstallFinalize. Flush any error return codes and write information into the MSI log instead. Then users could uninstall user data by specifying the property on the command line or hard code it in the Property table.
If you have to have a GUI you can use the same property to set from a custom dialog to control whether deletion is done or not. Remember to condition the display of the dialog with care. I.E don't show it during patching operations.