Integration Hurdles for EXE Custom Actions
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 ;^)
Integration Hurdles for EXE Custom Actions
Overview and Scope
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.
Integration Hurdles
The installation integrity risk running EXE custom actions come in a number of varieties
Problem |
Description |
Mitigation (by consumer of EXE) |
Crash | Bad EXEs can bring down the custom action sandbox | None |
Binary Dependency | 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. | None |
Load | Bad EXEs can expect to load DLLs from the path but the path could be customized by the user on the machine. | None |
Rights | Bad EXEs can require more rights (e.g. admin) than the package thus breaking scenarios (per-user) | None |
Logging | 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) |
UI | 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) |
Progress | EXEs do not have access to the widows installer progress bar. | None (best effort, add entries to the ReserveCost table) |
Hangs | 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) |
Costing | 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 - rollback behavior | 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. | None |
Uninstall | Bad EXEs do not support uninstall | None (best effort, build DLL that calls EXE uninstall if exists) |
Uninstall Rollback | Bad EXEs do not support uninstall rollback | None (best effort, build DLL that calls EXE install) |
Repair/Resiliency | Bad EXEs do not support repair | None (best effort, build DLL that calls EXE install again) |
First Run | Bad EXEs mix per machine installation with per-user installation that should be invoked at first run | None |
Error Codes | 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) |
Watson | 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) |
PSS Costs | 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) |
Localization | Does installation or manipulation by the EXE cause strings to be written to the system? If yes, how are the strings differentiated? | None |
Selection | 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 | None |
Group Policy (Publishing, assignment) | <missing this context> | None |
Debugging | 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 | None |
Servicing | EXEs are more difficult to confirm they contain the right security fixes when servicing | None |
Help | 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) |
Events | EXEs that produce events during install will appear outside the MSI context | None |
Customization | Numerous third party tools exist to customize an install to the needs of a particular specialized user (usually LORGs) | None |
File In Use | There is no way for a custom action to inform the user that files they want to manipulate are in use | None |
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. | None |
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. | None |
Reboot | If the EXE requires a reboot, there is no way to communicate the need for the REBOOT to the MSI | None |
Cancel | As EXEs can not call MsiProcessMessage, they are unable to respond to the cancel button. | None (best effort, build DLL that calls MsiProcessMessage) |
Watson | EXEs that crash may cause a Watson dialog during the install | None |
Test Scenarios
When testing the MSI that contains this EXE, one needs to test the following
- Deployment technologies
- Group Policy Software Distribution
- Publishing
- Assignment
- SMS deployment
- Install from network share/media
- Install from local cache
- Hard drive imaging
- Customer segments
- Retail install
- OEM pre-install
- Enterprise deployment
- User types
- No user (install during winlogon, install by SMS agent) - these will not have a user hive
- Lockdown user
- Regular user
- LUA without registry virtualization
- Admin user
[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.
Original post by Windows Installer Team