A while back, two sets of engineers were arguing whether simply calling an EXE custom action would be good enough for Windows Installer based package. The first team with the EXE didn't want to do the work to move to Windows Installer but they really wanted the second team to take a dependency. The team based on Windows Installer said the integration problems with calling an EXE was so great they would not integrate without a Windows Installer package.
As an attempt at arbitrating the disagreement, it was requested the Window Installer team provide an analysis. A quick paper was written to capture the analysis. This paper has since been shared in other similar circumstances.
In a recent instance, Microsoft blogger Aaron Stebner suggested this quick paper would make a good blog. Here it is. Hope it's useful ;^)
Windows Installer (MSI) architecture was designed to work best when all the installation behaviors are native to the Windows Installer. When the native behavior (called Standard Actions) are insufficient, there is a way to provide extend behavior (called Custom Actions). Custom Actions come in various base types that are differentiated on the way the Windows Installer service instantiates the custom action in the appropriate sandbox. Among the types of custom actions are executable files and dynamic link libraries.
Bare custom actions are risky to the integrity of a Windows Installer base install and this document will consider the risks.
This document will not dive deep into the architecture or the possibilities to improve the custom action architecture in the future.
The installation integrity risk running EXE custom actions come in a number of varieties
(by consumer of EXE)
Bad EXEs can bring down the custom action sandbox
Bad EXEs can require technologies that are not in the system at the time of the install. Specific instance: MSXML custom actions required MFC 7 but it didn't exist on machines.
Bad EXEs can expect to load DLLs from the path but the path could be customized by the user on the machine.
Bad EXEs can require more rights (e.g. admin) than the package thus breaking scenarios (per-user)
EXEs do not have access to the Windows Installer Log so there is no integrated troubleshooting.
None (best effort, build DLL that provides log path to EXE and puts the log next to or into the Windows Installer log)
EXE do not have access to the UILevel so they do not know whether it's OK to display UI.
None (best effort, build DLL that reads UILevel and alters command line)
EXEs do not have access to the widows installer progress bar.
None (best effort, add entries to the ReserveCost table)
EXE may hang and neither the Windows Installer nor the user has no way of knowing whether the install is hung or just taking a long time.
None (best effort, build DLL that calls CreateProcess and WaitForMultipleObjects)
EXE do not have any way of being integrated into the Windows Installer costing
None (best effort, build DLL that add ticks to the progress bar)
- rollback behavior- decision when to execute rollback (did failure occur in the FWD case thus calling the Backward case is extraneous?)
Bad EXE do not support rollback.
None (best effort, build DLL that calls EXE uninstall if exists)
Transparency and Predictability
EXEs are not data driven from the contents of the MSI thus are not transparent to users, especially admins.
Bad EXEs do not support uninstall
Bad EXEs do not support uninstall rollback
None (best effort, build DLL that calls EXE install)
Bad EXEs do not support repair
None (best effort, build DLL that calls EXE install again)
Bad EXEs mix per machine installation with per-user installation that should be invoked at first run
Bad EXEs do not provide return codes or have return codes that do not match the custom action return code expectations.
None (best effort, best effort, build DLL that interprets errors returned from the EXE and returns the appropriate value)
EXE failures are difficult to map to Watson buckets (for teams that have implemented Setup Watson)
None (best effort, build DLL that initializes Setup Watson with the needed context to differentiate EXE error)
When an EXE fails, the supports costs are absorbed by the enclosing product
None (best effort, build DLL that records needed context to differentiate EXE error)
Does installation or manipulation by the EXE cause strings to be written to the system? If yes, how are the strings differentiated?
Some EXEs have different levels that can be installed (Minimum, Full).
None (best effort, build DLL that maps UI or feature selection to different levels in EXE)
Terminal Server and SMS
Bad EXEs do not run correctly on Terminal Server where there is no user logged in and will not have a user hive
Group Policy (Publishing, assignment)
<missing this context>
There is no way to debug custom actions in EXE from MSI.
None (best effort, build DLL that uses dll debugging then alter EXE call from inside DLL)
Access to Database
EXEs are unable to access the database
None (best effort, build DLL that uses dll method to access the database)
Run From Source or Cache
EXEs are unable to be configured to run from source
EXEs are more difficult to confirm they contain the right security fixes when servicing
EXEs that contain 2.0 User Education integration may not have MSI's namespace parents configured at the time they are called
None (best effort, move the EXE to a different location in the sequence after the html help custom actions)
EXEs that produce events during install will appear outside the MSI context
Numerous third party tools exist to customize an install to the needs of a particular specialized user (usually LORGs)
File In Use
There is no way for a custom action to inform the user that files they want to manipulate are in use
Pending File Renames, File in Use, and Rollback
If a EXE custom action replaces files that are held in use and a MoveFileEx causes those files to end up in Pending File Renames, then the install rolls back it's possible that the files will still be changed on the next boot.
Detection of When to Install (Resiliency v Rollback)
A rollback during repair or reinstall could cause premature removal of a EXE install that existed on the machine before MSI was installed. If one implements rollback, one has to implement foolproof detection for existing installs of the component and not run the EXE package if the same version of EXE is already on the machine. Otherwise, a cancel or failure in the MSI could cause a preexisting installation of the EXE component to be removed.
If the EXE requires a reboot, there is no way to communicate the need for the REBOOT to the MSI
As EXEs can not call MsiProcessMessage, they are unable to respond to the cancel button.
None (best effort, build DLL that calls MsiProcessMessage)
EXEs that crash may cause a Watson dialog during the install
When testing the MSI that contains this EXE, one needs to test the following
[Author: Robert Flaming]This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.