The What’s New section of the Windows Installer 4.5 CHM available in the downloads section of the Windows Installer 4.5 Beta Connect site has technical details of new functionality and changes as usual, but now that we can talk about Windows Installer 4.5 I wanted to provide an overview of the new functionality. I’ll be detailing several topics in future posts.
The following features are new to Windows Installer 4.5 and provided both downlevel to Windows XP SP2 and newer, and to Windows Vista and newer.
Chaining installations often requires decisions about when to “undo” what has already been installed in previously installed products in the chain, and that must be done through maintenance installs to uninstall those products. With multi-package transactions, installation developers can now take advantage of the same transactional behavior as for a single product. Script generation and execution is still performed per-package, but the commit phase is performed for all products at the same time. If an error occurs, the rollback phase is performed for all products at the same time. This change in behavior extends to multi-product patch install as well.
Embedded UI Handlers
An external UI handler allows installation developers to present a single, consistent UI for chained products to the user. Office, Visual Studio, and many other product use them. The problem is when you want to compose your product by redistributing another product. Embedded UI handlers allow package developers to still handle and filter messages before they are dispatched to the standard UI handler. This feature also ties in with multi-package transactions by allowing a chained MSI to join an existing transaction.
Shared Components Robustness
Shared components prevent files from being uninstalled when another product is referencing those files. When components in different products have the same component GUID, those components are ref-counted. This feature does not, however, prevent files from being downgraded. When uninstalling a patch, providing the original source may be necessary and an older file may be reinstalled for one product and adversely affect another. Any components attributed with the new attribute msidbComponentAttributesShared (0x0800) will prevent such scenarios by making sure the newest file is reinstalled across all affected products.
Patch Supersedence Robustness
Patch supersedence allows patches to effectively hide other patches, thus working on a common baseline view of the product. This affects how patches are displayed in the Add/Remove Programs control panel, how to apply binary patches, and how patches are registered to products for future maintenance installs. Supersedence is, however, often tricky to get right. If a patch supersedes another patch, the superseding patch must contain all changes from a superseded patch. If, for example, a component is dropped in the superseding patch that a superseded patch added to the product, the components’ feature state is changed to Advertised and will not be reinstalled. Any components attributed with the new attribute msidbComponentAttributesUninstallOnSupersedence (0x0400) will simply be uninstalled if superseded out of the view of the product rather than affect its parent features’ states.
Uninstall Custom Actions
Uninstalling a patch is basically the act of removing the patch from the view of the product and reinstalling the product. If a patch being uninstalled added or updated custom actions, those custom actions will not be run during patch uninstall. In Windows Installer 4.5, custom actions attributed with the new attribute msidbCustomActionTypePatchUninstall (0x0800) will be run during uninstall and will be able to access changes a patch or patches made to the product even when they are being uninstalled. This allows package developers to avoid the rather cumbersome approach of authoring hooks in the baseline product or a previous patch that, for example, use patch codes in the MsiPatchRemovalList property to execute custom actions on disk or in the installation package.
In addition to all the applicable changes in Windows Installer 4.0 for Vista, some patch sequencer performance improvements were made along with other bug fixes. Not all of the functionality is active on downlevel platforms, however, such as the Restart Manager functionality that is new in the Windows Vista platform. More notable changes are summarized below.
The MsiLogging and MsiLogFileLocation properties are now available downlevel. The MsiLogging property is intended to allow the package developer to specify the default logging mode which overrides the default machine logging policy. The MsiLogFileLocation allows the installation UI developer to display the path to the log that MSI used – whether generated automatically or set otherwise using the MsiEnableLog() function.
Note: you should not use the MsiLogFileLocation property to write custom log lines to the Windows Installer log. Custom actions should always use the MsiProcessMessage() function.
Localized Basic UI
Localized text is now shown correctly for basic UI dialogs. In the absence of ActionText and Error table records, common UI text is provided by Windows Installer correctly based on the current UI language. No more blank dialogs as seen in Microsoft .NET Framework 2.0 patches.
Disable Registry Reflection
Registry reflection copies registry values between 32- and 64-bit views of the registry. Registry reflection is disabled for all registry keys and values affected by components attributed with the Windows Installer 4.0-introduced attribute msidbComponentAttributesDisableRegistryReflection (0x0200).