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.
Related
While I was searching for the answers I found that the registry entries are made during installation only. In my installer once the installation is done then there comes a dialogue box which contains one checkbox. Based upon the checkbox value I want to make the registry entry.
Please suggest.
All system modifications (such as file installation or registry modifications) should occur DURING installation. There is a REASON for that - to make installation transactional (all or nothing), and to allow clean uninstall and repair.
Suggestion: if you want to put some user setting (a-la 'user agreed to receive marketing emails'), better do it yourself (as a custom action for example). Or better yet, in your own program (do not put it in the MSI installer)
A custom action in principle can be run in any execution sequence (including UI sequence), so you will be able to run it any time (i.e. even after that dialog)
Another option is to collect data (checkbox value) BEFORE install. Then you can include it as part of normal install sequence (as registry element)
I have a custom bootstrapper that allows the user to uninstall components of the installation or the entire installation. In either situation, the bootstrapper is removed and no longer available in 'Programs and Features'. Is there a way I can prevent the bundle from being removed if I know the user is just uninstalling a component of the installation?
I thought maybe I could set the installation state to modify but I don't see a way to do that.
During the Plan phase, you need to handle a handful of events to set the State you want for each MsiFeature and Package within your bundle.
For each wix msifeature and/or package the user is changing, you'll need to set the State value of the event args to AddLocal or Remove for features, and Present or Absent for packages during the planning phase event handlers (BootstrapperApplication.PlanPackageBegin and BootstrapperApplication.PlanMsiFeature). For any remaining unchanged, set the state to None.
Then, when you call Engine.Plan(...), you'll need to provide a LaunchAction value of Modify or Install if you want the bootstrapper to exist after the run, or Uninstall if you want to have the bootstrapper removed. I suspect this is where you're having issues -- check what value you're passing to Plan()
I wrote a series of blog posts you may find helpful (particularly part 5): Writing Your Own .NET-based Installer with WiX
Is there a difference between uninstalling an application with WiX based .msi from Control Panel and from the .msi itself?
If there is what is it?
I am asking because of the following reason:
The difference is the following: my .msi stores some files in %PROGRAMDATA%. If i uninstall from Control Panel the files there get uninstalled (it seems that the .msi keeps track of those (they are defined as components)), but when I open my .msi and try to uninstall (I have a maintenance dialog) those files don't get deleted.
Another difference is: I also have a Custom Action to stop my Application if it is running which is being called After="AppSearch" in the InstallUISequence and Before="CostFinalize" in the InstallExecuteSequence but when removing from the .msi it isn't being called. Only a dialog shows that says that there are files to be deleted but are being usedbut some processes and when I tell it to stop them it doesn't do so.
The following "discussion" got a little out of hand. But I will leave it here as an explanation for people who research differences experienced between silent mode and interactive mode installs.
Yes, the short answer is that you can indeed see different installation or uninstallation behavior depending on how you invoke the (un)install.
This has mostly to do with how an MSI can run with different user interface levels, and this causes the entire user interface sequence (InstallUISequence) in the MSI to either be run or skipped entirely (silent installation). Once skipped, all custom actions defined only in the InstallUISequence will not run at all. If the MSI is well-designed, this is not a problem since user interface custom actions run in immediate mode and should never make changes to the system - they should just inquire for user data and settings, system state or help the user enter proper data for the installation. If the MSI is not well designed and changes are made to the system in the user interface, the installation will be incomplete when running in silent mode. This is a serious MSI design error which becomes all the more serious when you realized that all major corporations deploy software silently. I have seen such errors many times when doing corporate application repackaging. It is not a vote of confidence for the software, no matter how good it is. Weird and unpredictable problems are bound to surface.
Accordingly, the InstallExecuteSequence (which is the only one that runs when the setup is installed silently) should have all required custom actions that make system changes inserted there for an MSI to be correctly designed. As already stated, custom actions existing only in the user interface sequence should deal with getting values and settings from the user, whereas these values should be set and defined by command line or defined in transforms for a silent install.
Certain odd and erroneous combinations of custom action conditions can also cause differences between interactive and silent installs in special circumstances. And finally putting custom actions after InstallFinalize in the InstallExecuteSequence can cause actions to fail when run silently. There are certainly other potential problems as well.
In summary, if you do see a difference in installation behavior based on the user interface level, your MSI contains a serious design-flaw. You should always ensure that your MSI can be run silently with the equivalent result as interactively. And as already stated large corporations never run installations interactively since they push out software via software management systems such as SCCM.
There are 4 MSI UI levels ranging from fully silent to fully interactive:
INSTALLUILEVEL_NONE = 2, (totally silent)
INSTALLUILEVEL_BASIC = 3, (progress bars and simple error handling)
INSTALLUILEVEL_REDUCED = 4, (authored UI, no wizards)
INSTALLUILEVEL_FULL = 5 (full UI)
The important point is that for UILevel 2 and 3 the InstallUISequence is skipped.
There is an MSI property UILevel holding the GUI level value 2, 3, 4 or 5. Check this property if your custom action must take the user interface type into account. This is obviously most important for totally silent installs that should never show any dialogs.
When you right click an MSI and select uninstall you are generally running UILevel 3 (Basic UI with progress bar). This means the InstallUISequence is skipped.
When you uninstall from Add/Remove programs the normal UILevel is also 3 - basic user interface. This means the InstallUISequence is also skipped.
If you double-click the MSI and run uninstall, your GUI level is 5 - full GUI. The same happens if you select "Change" in add/remove programs.
In summary, it is possible for bugs to occur in only one of the modes (silent / non-silent) because the MSI's user interface sequence is skipped along with all its custom actions for certain user interface levels. In other words, a product could work when installed interactively and fail when installing silently (or vice versa), if the MSI is badly designed.
It is also possible to condition custom actions in the main MSI installation sequence erronously based on this UILevel feature so that results differ based on installation mode. I have seen people spawn dialogs from code in custom actions placed in the main installation sequence (where no interactivity is allowed) and then use UILevel checks to suppress the dialog in silent installation mode (or they forget that as well, triggering a hidden modal dialog that stops the install dead when running in silent mode). These weird design constructs cause unexpected installation behavior based on how the install is triggered and run.
Though this is sort of not an answer to what you asked, a final conclusion from all of this is that if your software is intended for large corporations you should not waste your design efforts on an advanced GUI for your setup as it is likely never to be used for large-scale deployment scenarios. Rather you should parameterize your installer with public properties that can be set at the command line or via a transform so that your installer can be controlled easily without running it interactively. See this post: How to make better use of MSI files.
Since I have gone so far beyond your question, I should also note that some advanced installers intended for server installations may (with moderation) benefit from a good GUI to help people quickly get your server software installed and tested. These installers tend to meddle with very advanced features such as IIS, MS SQL, AD, etc... and some interactivity could be desired for knowledgeable system administrators. But as the saying goes "most things can default" and good default settings are generally easier for people to get installed and tested whether knowledgeable or not. Many large companies run large farms of server virtuals these days (one virtual server per use case), so even server installs tend to get automated for large-scale rollout and then a good parameterized installer with public properties to set is appreciated. Smaller companies may also have server virtuals (making testing easy), but they are likely to install your setup interactively accepting whatever defaults are there - at least that is my impression.
Links:
Is it possible to passively install an .EXE but still show the GUI using Powershell?
There is no practical difference between right-clicking an MSI to uninstall it, and using Control panel to uninstall it. Both result in a minimal UI (not totally silent, shows progress bar) uninstall, and will ask for elevation if required.
If you have a maintenance mode dialog in your setup then you may have a slightly different path - you may show a dialog that offers to change features, repair, or uninstall. That might result in a difference somewhere.
If there is some code somewhere that alters something, then who knows? An uninstall from a dialog might choose to suppress the Cancel button, as a random example.
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.