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.)
Related
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 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.
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'm writing a WLST script to deploy some WAR's and an EAR. However, intermittently, the script will time out because it can't seem to get an edit lock (this script is part of a chain of many other scripts). I was wondering, is there a way to override or stop any current locks on the server? This is only a temporary solution, but in the interest of time, it will do for now.
Thanks.
You could try setting a wait period and timeout:
startEdit([waitTimeInMillis], [timeoutInMillis], [exclusive]).
Are other scripts erroring out, leaving the session locked? You could try adding exception handling around those. Also, if you have 'Automatically acquire lock" enabled in the Admin Console and you use the admin console sometimes it can cause problems if you are running scripts at the same time, even though you are not making "lock-requiring" changes.
Also, are you using the same user for the chained scripts?
Within WLST, you can pass a number as a parameter to gain an exclusive lock. This allows the script to grab a different lock than the regular one that's used whenever an administrator locks from the console. It also prevents two instances of the same script from stepping on each other.
However, this creates complex change merge scenarios that are best avoided (by processes).
Oracle's documentation on configuration locks can be found here.
Alternatively, if you want the script to temporarily relieve any existing locks regardless of the pending changes, you may as well disable change management from the console, minimizing the inconvenience caused.
WLST also contains the cancelEdit command that you could run before you startEdit. Hope one of these options pan out!
To take the configuration change lock from another administrator:
If another administrator already has the configuration lock, the following message appears: Another user already owns the lock. You will need to either wait for the lock to be released, or take the lock.
Locate the Change Center in the upper left corner of the
Administration Console.
Click Take Lock & Edit.
Make your configuration changes.
In the Change Center, click Activate Changes. Not all changes take
effect immediately. Some require a restart (see Use the Change
Center).
As long as you're running WLST as an administrative user, you should be able to jump into an existing edit session with the edit() command - I've done a quick test with two admin users, one in the Admin Console, and one using WLST, and it appears to work fine - I can see the changes in the Admin Console session inside the WLST interpreter.
You could put a very simple exception handler around your calls to startEdit that will log the exception's stack trace, but do nothing else. And then rely on the edit call to pop you into the change session.
Relying on that is going to be tricky though if another script has started an edit session and is expecting to be able to commit that change session itself - you'll be getting exceptions and unreliable behaviour across multiple invocations.
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.