Another Workaround to Add New Components to Existing Features

Heath Stewart

February 19th, 20080 0

Yesterday I described an issue when adding new components to existing, not-installed (absent) features the feature tree is installed. This can lead to prompts for source or failed installations.

One workaround is to add new, top-level hidden features. This works well unless new resources have a dependency on the older resources installed by the would-be feature tree – the feature tree where the new components should’ve been parented.

Another workaround is to reinstall everything by setting REINSTALL=ALL. Setting any of the feature, component, or file selection properties listed below bypasses Windows Installer’s functionality that automatically determines what to install or reinstall (available in Windows Installer 2.0 and newer).

While this prevents the issue described above when adding new components to existing, absent feature, the problem is that if you do add new features in your patches, you’ll need to manage ADDLOCAL yourself as well.Workaround2 in the attached example WiX projects sets REINSTALL and also adds a new feature, but you can see from the feature state in the log that the feature “Workaround” is not installed.

MSI (s) (F8:B0) [15:16:04:886]: Feature: NotInstalled; Installed: Absent; Request: Null; Action: Null MSI (s) (F8:B0) [15:16:04:886]: Feature: Example; Installed: Local; Request: Reinstall; Action: Reinstall MSI (s) (F8:B0) [15:16:04:886]: Feature: Servicing; Installed: Local; Request: Reinstall; Action: Reinstall MSI (s) (F8:B0) [15:16:04:886]: Feature: Workaround; Installed: Absent; Request: Null; Action: Null

Managing properties like ADDLOCAL with custom actions can be very tricky. If you add a feature or features to ADDLOCAL and any of these features are parented to existing, absent features, that feature tree is still installed; and a prompt for source or installation failure will still happen. If you create custom actions as shown in the WiX example below that are conditioned on parent feature states, those custom actions must be scheduled after CostFinalize but then it is practically too late to change feature state without re-costing by calling CostFinalize again. This potentially causes the same problem as when using type 35 custom actions carelessly.

<CustomAction Id="SetADDLOCAL_Workaround" Property="ADDLOCAL" Value="{[ADDLOCAL];}Workaround"/>

If you are not adding features in a patch, you may be fine setting REINSTALL=ALL. Note that this does incur a performance penalty to re-cost every feature and can potentially end up repairing a feature with a missing file that you’re not patching, which in turn may lead to a prompt for source or installation failure. For products with few features this workaround should be appropriate.

Example.zip