InstallSite Blog : Tips

Careful with that Hyperlink (on your MSI dialog)

stefan — Fri, 18 Sep 2009 19:51:16 GMT

One of the new features in version 5 of the Windows Installer runtime is support for hyperlink controls on setup dialogs. Remember that MSI 5 is only available on Windows 7 and Windows Server 2008 R2, but there's no redistributable for down-level platforms.

In most cases when introducing new features, the MSI team made sure they don't break your setup on older runtime versions. For instance, older MSI versions simply ignore new tables that they can't use. This enables developers to create a setup that will run with basic functionality on older platforms but on the latest MSI version the new features would "light up".

The hyperlink control is different, maybe because it's not a table but a new control type in an existing table, the Control table. Thus, it causes your setup to fail on Windows Installer versions prior to MSI 5:

Dialog with hyperlink control on Windows 7

Dialog with hyperlink control on Windows Vista

Error code 2885 means "Failed to create the control [3] on the dialog [2]."

Workaround

To work around this issue, create two versions of the dialog, one with the hyperlink control, and the other without. Use these condition to display the appropriate dialog:

VersionMsi >= "5.00" (for the dialog with hyperlink control)
VersionMsi < "5.00" (for the dialog without hyperlink control)

Note that making the hyperlink control invisible for MSI versions < 5 doesn't help. You really need a separate dialog.

How to create a hyperlink control (if your tool doesn't support it)

I've used Advanced Installer to create the above screen shots, because its dialog editor can create hyperlink controls. If you are using InstallShield or another tool that doesn't support hyperlink controls (yet) but has a way to modify the msi tables directly, you can create a hyperlink control using these easy steps:

Create a static text control
Set its text in HTML format: like this:
<a href=http://www.installsite.org>www.InstallSite.org</a>
where the href parameter specifies the URL and the text between the opening and the closing tag is what gets displayed.
Go to Direct Editor and select the table named Control.
Find your text control and change the Type from Text to Hyperlink.

This manual procedure even gives you more flexibility. For instance you could hyperlink only part of the text, while in Advanced Installer the complete text is hyperlinked. The following screen shot was created with InstallShield using this string for the Hyperlink Text:

Please visit <a href="http://www.installsite.org">InstallSite.org</a> for more samples

Microsoft's recent Security Updates for Visual Studio break Windows Installer Updates

stefan — Sat, 12 Sep 2009 00:30:44 GMT

This problem was brought up in a question on the InstallSite Forum and is also mentioned in a blog post by Gauravb (who appears to be a Microsoft employee).

The typical symptom is missing or not updated files after you install a Small or Minor Update to your application (Major Upgrades are not affected). In the installer log file you'll notice that some features have been switched to "advertised" state and instead of being installed locally. The actual cause is noted in the SELMGR error message in the log similar to this:

SELMGR: ComponentId '{-GUID-}' is registered to feature '-Feature-Name-', but is not present in the Component table. Removal of components from a feature is not supported!

This happens if your setup includes a merge module like Microsoft_VC80_CRT_x86.msm and you rebuilt your setup package after installingsecurity updates 971090 and 973673 for Visual Studio 2005 SP1 or 971092 and 973675 for Visual Studio 2008 SP1. These security updates install newer versions of merge modules.

Apparently a component that existed in the original version of the merge module has been removed in the updated msm. Removing a component is a violation of Windows Installer's rules for Small and Minor Updates.

Affected Merge Modules and GUIDs

Visual Studio 2005 SP1

I examined to merge modules installed by Visual Studio 2005 SP1 and updated by by security updates 971090 and 973673. I found that all of these merge modules are affected by this problem, i.e. they have components removed:

Microsoft_VC80_ATL_x86.msm
Removed 2 components with GUIDs {9B2CAF3C-B0AB-11EC-B01F-C8B3B9A1E18E} and {9B2CAF3C-B0AB-11EC-C01F-C8B3B9A1E18E}
Microsoft_VC80_CRT_x86.msm
Removed 2 components with GUIDs {9BFFB8F8-F55F-10B2-C01F-C8B3B9A1E18E} and {9BFFB8F8-F55F-10B2-B01F-C8B3B9A1E18E}
Microsoft_VC80_DebugCRT_x86.msm
Removed 2 components with GUIDs {583FF03B-A196-24C8-C01F-C8B3B9A1E18E} and {583FF03B-A196-24C8-B01F-C8B3B9A1E18E}
Microsoft_VC80_DebugMFC_x86.msm
Removed 2 components with GUIDs {55141F6E-A388-29A8-C01F-C8B3B9A1E18E} and {55141F6E-A388-29A8-B01F-C8B3B9A1E18E}
Microsoft_VC80_DebugOpenMP_x86.msm
Removed 2 components with GUIDs {8E601675-4F66-A4DE-B01F-C8B3B9A1E18E} and {8E601675-4F66-A4DE-C01F-C8B3B9A1E18E}
Microsoft_VC80_MFC_x86.msm
Removed 2 components with GUIDs {9EE2A7ED-8A13-0C17-C01F-C8B3B9A1E18E} and {9EE2A7ED-8A13-0C17-B01F-C8B3B9A1E18E}
Microsoft_VC80_MFCLOC_x86.msm
Removed 2 components with GUIDs {7831D131-CCF1-43EF-C01F-C8B3B9A1E18E} and {7831D131-CCF1-43EF-B01F-C8B3B9A1E18E}
Microsoft_VC80_OpenMP_x86.msm
Removed 2 components with GUIDs {218504D2-AA7D-7B33-B01F-C8B3B9A1E18E} and {218504D2-AA7D-7B33-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_ATL_x86.msm
Removed 1 component with GUID {6967BA9D-3E8C-8E05-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_CRT_x86.msm
Removed 1 component with GUID {671DDE41-A620-9193-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_DebugCRT_x86.msm
Removed 1 component with GUID {5A7EB616-E2EE-6D78-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_DebugMFC_x86.msm
Removed 1 component with GUID {5D61A50B-77A2-68DD-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_DebugOpenMP_x86.msm
Removed 1 component with GUID {8506B23C-BABD-5C8B-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_MFC_x86.msm
Removed 1 component with GUID {6BEC5B24-C056-8A14-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_MFCLOC_x86.msm
Removed 1 component with GUID {D5A7A18A-DEA5-8DD7-C01F-C8B3B9A1E18E}
policy_8_0_Microsoft_VC80_OpenMP_x86.msm
Removed 1 component with GUID {07EE8801-38A9-ABAC-C01F-C8B3B9A1E18E}

Visual Studio 2008 SP1

I also examined to merge modules installed by Visual Studio 2008 SP1 and updated by by security updates 971092 and 973675. I found that all of these merge modules are affected by this problem, i.e. they have components removed:

Microsoft_VC90_ATL_x86.msm
Removed 4 components with GUIDs {2F605F26-3021-38F6-AC31-175C0DFA59B9}, {76C3F0F6-9B9D-35DA-81C6-CA8A88CC93CA}, {DBD31579-020A-349E-8ED6-D06FEA75AF45}, and {86226397-23DB-3430-8C8A-AEA661B1AE77}
Microsoft_VC90_CRT_x86.msm
Removed 4 components with GUIDs {AEC90EFE-39B8-3978-8A5D-068FEF83D275}, {B708EB72-AA82-3EB7-8BB0-D845BA35C93D}, {1A5C156B-3CC3-36E3-BAD7-9FD0D48156D3}, and {68D7E2DF-5BC5-318C-AF19-19D1D29ED692}
Microsoft_VC90_DebugCRT_x86.msm
Removed 4 components with GUIDs {58425F02-9D68-3D93-85D9-39B29E29BC7B}, {BAD864A4-C2C0-3C54-8964-B268B7016DEC}, {FC82857E-2B1F-3E92-A906-97FD9825D3C7}, and {0BDD8003-3267-389F-813F-AD12EC5DC534}
Microsoft_VC90_DebugMFC_x86.msm
Removed 4 components with GUIDs {F0A00871-E0E2-32B2-A659-FE4DA7002A2D}, {342BA686-A9E6-3FB4-AFC0-7034FF188D52}, {7E7F1AD6-F52E-3AE6-BAA5-32B96EE05F4E}, and {B833CE77-211C-355F-9DBB-294FD746EF17}
Microsoft_VC90_DebugOpenMP_x86.msm
Removed 4 components with GUIDs {5586775C-EA44-30E2-A3E2-5C50F4EA39A0}, {B0C784B6-DDCC-3D69-A33A-5DE42951883C}, {E59B8FDA-55AE-3049-96FC-606E8C5BF2BE}, and {8FD717AF-E0E2-365E-8445-AECD9A21E5A0}
Microsoft_VC90_MFC_x86.msm
Removed 4 components with GUIDs {D01CBF08-20B4-30C8-AF5A-96F9847E82A3}, {C6357C55-7461-3D51-9AE5-FD71CA24027A}, {611881C8-BE2F-393E-A04F-81C63DF00851}, and {15F67BFD-D6AA-3C8B-A1BB-C33E17E925C6}
Microsoft_VC90_MFCLOC_x86.msm
Removed 4 components with GUIDs {5A06E1CC-89C9-3DB9-9BC8-5BFA56B58BFB}, {FF2F571A-6C54-31E3-B23E-2A60283B08A8}, {C9F2C40F-28CD-392C-A0C3-3AADEC130C0A}, and {4D8012CE-B2CE-3493-91B8-B8A9B982F6B8}
Microsoft_VC90_OpenMP_x86.msm
Removed 4 components with GUIDs {A85D53AA-906D-31C5-96E3-E21BB9154E2C}, {D511F4F3-A911-32CF-AC11-9C97EF948BFC}, {B16F86FC-BD94-30FA-98AA-17ABE54F0478}, and {28B6B10C-E41F-302B-A673-01F436427522}
policy_9_0_Microsoft_VC90_ATL_x86.msm
Removed 2 components with GUIDs {A62CCE52-C380-3111-BA7D-3D0EDFA31213} and {C2FCD113-35CA-3027-92CD-F2D646277CA1}
policy_9_0_Microsoft_VC90_CRT_x86.msm
Removed 2 components with GUIDs {14F2B62D-DF5F-335F-A517-0991F44CB087} and {0355F5D0-467C-30E9-894C-C2FAEF522A11}
policy_9_0_Microsoft_VC90_DebugCRT_x86.msm
Removed 2 components with GUIDs {C990308F-4696-3069-B753-AB178CE2007B} and {FBB763D7-1B85-36C2-B127-4577B3FC45A1}
policy_9_0_Microsoft_VC90_DebugMFC_x86.msm
Removed 2 components with GUIDs {9B8A0715-C004-3493-8350-A387E1163D46} and {9EC89F44-FA15-308D-8582-22744424F0CF}
policy_9_0_Microsoft_VC90_DebugOpenMP_x86.msm
Removed 2 components with GUIDs {A134D5FD-99B1-3230-89AC-C4F81B697BFC} and {19185A82-2047-34BF-BBE1-5E64579BE356}
policy_9_0_Microsoft_VC90_MFC_x86.msm
Removed 2 components with GUIDs {6BFBB2DC-4F78-3217-ACCF-CD2838A84621} and {12EA53B4-340A-3F5D-B1BC-4A3BEC4A89A7}
policy_9_0_Microsoft_VC90_MFCLOC_x86.msm
Removed 2 components with GUIDs {0FEBA8D0-5D22-3D3A-947D-559E29BF07DF} and {6F026C46-D6BC-3805-A3B0-117AF8473928}
policy_9_0_Microsoft_VC90_OpenMP_x86.msm
Removed 2 components with GUIDs {8D71CE57-BDC3-34B0-ADAD-EA4C5AFC9664} and {649A198A-C19D-325F-BF3A-C7EAE62F5EF6}

Workarounds

This means that if your setup includes any of these merge modules, the security update prevents you from shipping Small or Minor Updates.The workaround I'd recommend is using a Major Upgrade (i.e. change the ProductCode and add an entry in the Upgrade table) to update your application.

Gauravb's blog lists some other workarounds which I don't think are feasible:

Use the VC Redistributable Installer EXE package to install the runtime instead of the merge modules. - Good advice for new packages or Major Upgrades, but you can't remove the merge modules from your package in a Small or Minor Update.
Use the old verion of the merge modules, - This means you would knowingly be installing a vulnerable file on your customer's computer.

Another potential workaround would be to add dummy components to your msi setup with the same GUIDs as the components that were removed from the merge modules. But that could cause conflicts with other msi files that include the original version of the module.

DON'T Clean up your PC with Windows Installer Clean Up Utility

stefan — Sat, 25 Jul 2009 10:18:00 GMT

Currently there are many Twitter posts suggesting the Windows Installer Clean Up Utility. This concerns me and I want to clarify some things about it.

I think these tweets might have been triggered by a blog article that Karl L. Gechlik posted recently: Clean up your PC with Windows Installer Clean Up Utility

The Windows Installer CleanUp Utility (MSICU) is a last resort to work around problems with broken or partially installed Windows Installer (MSI) packages if the regular measures like uninstalling from Add/Remove Programs control panel have failed. However it is not intended for routine maintenance of your computer.

When you install a program with a setup that is based on Windows Installer technology, information about that program is registered in the Windows Installer database. If this information or the setup program itself gets corrupted you may not be able to uninstall or re-install this program, and you might even be unable to install other programs. MSICU can delete such corrupted information in the Windows Installer database.

The first caveat is that it can also remove this information for setup packages that are not corrupted. If you delete such information you will no longer be able to uninstall or maintain the respective program. Using MSICU you can severely damage your system configuration. If it ain’t broke, don’t fix it!

There’s also a misconception about MSICU and this is reflected in the following statement in Karl Gechlik’s blog:

It runs through the registry using command line options to search and remove registry items associated with your application and then it grabs and deletes shared dll’s and other files.

This is not quite correct. MSICU only removes information from the Windows Installer database. It does not remove registry items like COM registration, nor does it delete any program files (including shared DLLs).

If you look carefully at the lines I highlighted in the above screenshot (which I borrowed from Karl’s blog) you’ll notice that they say:

Removed shared DLL entry: …

Windows keeps a reference count for DLL files that are shared between multiple applications in the registry. This count is used to determine when no application needs the file anymore so that it can savely be deleted. MSICU decrements this counter, but it doesn’t delete the file itself.

The documentation on the MSICU download page also makes this clear:

Be aware that Windows Installer CleanUp Utility will not remove the actual program from your computer. However, it will remove the installation files so that you can start the installation, upgrade, or uninstall over.

So the second caveat: MSICU will not delete files (except the cached .msi file), it will not regain “wasted” disk space, it will not clean your registry, it will not make your computer faster. Quite the opposite: it will leave all installed files on your hard disk as orphans.

To summarize: MSCU is a useful tool if you face a problem with a corrupted Windows Installer package, but most Windows users should never need to use it.

Windows Installer Version Matrix

stefan — Sat, 26 Jul 2008 20:08:13 GMT

This table shows released Windows Installer versions that are included or available as redistributables for the different versions of Windows. Pre-release or beta versions are not listed.

The data have been collected from various sources. If you find any inaccuracies or have additional information that should be added, please let me know: skrueger (at) installsite.org

This table is also available in my MSI FAQ (English / German) where you can always get the latest version.

version	Windows Installer version that is included in this Windows version
version	Windows Installer version that can be installed on this Windows version, link points to download location
--	Windows Installer version is not supported on this Windows version
	not applicable, i.e. newer version is already included with this Windows version

Windows Server 2008	4.5	4.0	3.1 Security Update	3.1 (v2)	3.1	3.0	2.0	1.2	1.1	1.0
Windows Server 2008	4.5.6001.22162	4.0.6001.18000
Windows Vista	4.5	4.0	3.1 Security Update	3.1 (v2)	3.1	3.0	2.0	1.2	1.1	1.0
Windows Vista SP1	4.5.6001.22162	4.0.6001.18000
Windows Vista	4.5.6000.20817	4.0.6000.16386
Windows Server 2003	4.5	4.0	3.1 Security Update	3.1 (v2)	3.1	3.0	2.0	1.2	1.1	1.0
Windows Server 2003 SP2	4.5.6001.22159	--	3.1.4000.4042	3.1.4000.3959
Windows Server 2003 SP1	4.5.6001.22159	--	3.1.4000.4042	3.1.4000.2435	3.1.4000.1830
Windows Server 2003 (64 bit)	--	--		--	--	3.0.3790.2180	2.0.3790.0
Windows Server 2003 (32 bit)	--	--	3.1.4000.4042	3.1.4000.2435	3.1.4000.1823	3.0.3790.2180	2.0.3790.0
Windows XP	4.5	4.0	3.1 Security Update	3.1 (v2)	3.1	3.0	2.0	1.2	1.1	1.0
Windows XP SP3	4.5.6001.22159	--	3.1.4001.5512	3.1.4001.5512
Windows XP x64 RTM	--	--	3.1.4000.4042	3.1.4000.2435	3.1.4000.1830
Windows XP SP2	4.5.6001.22159	--	3.1.4000.4039	3.1.4000.2435	3.1.4000.1823	3.0.3790.2180
Windows XP SP1	--	--	3.1.4000.4039	3.1.4000.2435	3.1.4000.1823	3.0.3790.2180	2.0.2600.1106
Windows XP	--	--	3.1.4000.4039	3.1.4000.2435	3.1.4000.1823	3.0.3790.2180	2.0.2600.0
Windows 2000	4.5	4.0	3.1 Security Update	3.1 (v2)	3.1	3.0	2.0	1.2	1.1	1.0
Windows 2000 SP4	--	--	3.1.4000.4033	3.1.4000.2435	3.1.4000.1823	3.0.3790.2180	2.0.2600.1183
Windows 2000 SP3	--	--	--	3.1.4000.2435	3.1.4000.1823	3.0.3790.2180	2.0.2600.1
Windows 2000 SP2	--	--	--	--	--	--	2.0.2600.2 2.0.2600.0	--	1.11.2405.0
Windows 2000 SP1	--	--	--	--	--	--	2.0.2600.2 2.0.2600.0	--	1.11.1314.0
Windows 2000	--	--	--	--	--	--	2.0.2600.2 2.0.2600.0	--	1.10.1029.0
Windows 9x	4.5	4.0	3.1 Security Update	3.1 (v2)	3.1	3.0	2.0	1.2	1.1	1.0
Windows Me	--	--	--	--	--	--	2.0.2600.2 2.0.2600.1 2.0.2600.0	1.20.1410.0
Windows 98 SE	--	--	--	--	--	--	2.0.2600.2 2.0.2600.1 2.0.2600.0	1.20.1827.1	1.10.1029.1	1.0.5104.0
Windows 98	--	--	--	--	--	--	2.0.2600.2 2.0.2600.1 2.0.2600.0	1.20.1827.1	1.10.1029.1	1.0.5104.0
Windows 95	--	--	--	--	--	--	2.0.2600.2 2.0.2600.1 2.0.2600.0	1.20.1827.1	1.10.1029.1	1.0.5104.0
Windows NT 4	4.5	4.0	3.1 Security Update	3.1 (v2)	3.1	3.0	2.0	1.2	1.1	1.0
Windows NT 4.0 SP6	--	--	--	--	--	--	2.0.2600.2 2.0.2600.0	1.20.1827.1	1.10.1029.1	1.0.5104.0
Windows NT 4.0 SP5	--	--	--	--	--	--	--	1.20.1827.1	1.10.1029.1	1.0.5104.0
Windows NT 4.0 SP4	--	--	--	--	--	--	--	1.20.1827.1	1.10.1029.1	1.0.5104.0
Windows NT 4.0 SP3	--	--	--	--	--	--	--	1.20.1827.1	1.10.1029.1	1.0.5104.0
Windows NT 4.0 < SP3	--	--	--	--	--	--	--	--	--	--

The good, the bad, and the ugly - custom action types

stefan — Wed, 21 Nov 2007 15:15:41 GMT

I'd like to add my thoughts to the recent discussion about how bad custom actions are, and which types are better or worse than others.

First of all, I believe there's a general consent that custom actions shouldn't be used for tasks that Windows Installer supports natively. Or, as Rob Mensching puts it: "Custom actions are (generally) an admission of failure" - either by the setup developer, or in the application, or by Windows Installer itself, because it's lacking some commonly required functionality.

Rob is the project leader of the open source WiX Toolset for creating Windows Installer setups. Part of the WiX project is a set of custom actions for common tasks such as interacting with IIS and SQL Server. Some people wish that such functionality would be added to Windows Installer itself, but I believe that won't happen. Alternatively the SQL, IIS, etc. teams could provide custom actions for their respective platforms, like the DIFx people did, but in most cases this hasn't happened either.

So we'll have to use custom actions, to retrieve information and set properties in the install, and to modify the target system. In general, the latter is more dangerous than the first, and requires additional effort such as creating a corresponding roll-back action.

There are even harmless types of so-called "custom actions" which are actually more like standard action: type 51 (set a property), type 35 (set a directory) and type 19 (exit with an error message).

But the discussion really is about whether EXE is worse than DLL and which programming language should be used to create custom actions. Windows Installer natively supports the following types of custom actions:

VBScript, JScript - These don't work on some machines, if scripting is disabled. They can also make your setup look very evil if a virus scanner flags it as potential malware (think of Office macro viruses). If the script becomes complex, it's also hard to debug.
EXE - Works, but doesn't have a way to communicate back to the install. So you can't return information in properties, you can't increment the progress bar and the only return values recognized by Windows Installer are success or failure. Robert Flaming of the Windows Installer team at Microsoft lists some caveats for EXE custom actions. Note that some of the problems he lists apply to "bad EXEs", so there is a chance to make it better. Also there are valid reasons to use EXE custom actions, e.g. you may already have a working and tested configuration tool which you want to re-use instead of rewriting it as DLL.
DLL - Typically a very robust and versatile way to create a custom action. However you should avoid runtime dependencies.

There are third party extensions that enable you to use other types of custom actions. Christopher Painter argues that "InstallScript Custom Actions are GOOD". To the Windows Installer engine they appear as DLL (the InstallScript engine) and InstallScript is a language particularly for setup related tasks. However I believe that the tasks of a custom action often aren't typical installation tasks (copying files, accessing the registry) but require calling some APIs to interact with other applications. On the other hand, it's tempting to use InstallScript to perform tasks that actually should be left to Windows Installer's standard actions. So InstallScript custom actions, while they may be useful, should be used with care. And they add the overhead, in package size and runtime, of the InstallScript engine. In general, I think it's useful to write custom actions in the programming language you know best.

As mentioned in the beginning of this article, a custom action should never be used for tasks that Windows Installer supports natively. Unfortunately this still happens. Sometimes because the setup developer is lacking knowledge about the functionality included in the MSI engine, but probably more often because the authoring tool he's using doesn't expose the full Windows Installer functionality. This leads the developer to re-invent the hidden functionality using custom actions. Namely Setup & Deployment projects in Visual Studio suffer from this problem.

The ultimate form of such a custom action is a "wrapper msi": a msi setup that mainly consist of one custom action that runs an existing setup program. Instead of re-building the setup as true Windows Installer setup, the legacy install package is just wrapped in a msi. While this enables you to deploy the wrapped setup using corporate deployment tools, you don't get the benefits of a real Windows Installer setup, such as a transacted install with rollback, customizability with transforms, robustness by auto-repair, etc. A recent example is the MSI package created by the Internet Explorer Administration Kit.

Here are some pointers to built-in Windows Installer functionality which can help you to avoid unnecessary custom actions:

Searching for Existing Applications, Files, Registry Entries or .ini File Entries
MoveFile to copy or move files before the installation starts
DuplicateFile to create copies of the files your setup installs, and to remove them on uninstall
RemoveFile to delete files that are not included in your setup, during install or uninstall
RemoveRegistry to delete registry information during installation
ServiceInstall to create services and specify their start type and error handling
ServiceControl to start, stop, or delete services

[Edit 2007-11-25:] Additional information and mitigation tips for EXE custom actions can be found in Heath Stewart's blog.

Prepare for MSI 4.5

stefan — Wed, 29 Aug 2007 10:58:00 GMT

The first public beta version of the Windows Installer (MSI) 4.5 runtime, SDK and documentation has just been posted by Microsoft. It's mainly targeted at tools vendors so they can update their authoring and packaging tools to support the new version. But as a setup developer you should also prepare for MSI 4.5, and below are some suggestions how yu can do this. Before you can download the beta files and documentaton, you must register at the Microsoft Connect site, where you can also report bugs and problems - see the Walkthrough for Signing up for Windows Installer 4.5 Beta.

Note: if you are an end user (not developing msi packages) I don't recommend installing MSI 4.5 at this point.

Read the documentation

White papers explaining the goals and changes in MSI 4.5 as well as SDK documentation (msi.chm) are available on the Connect site. Read them to see if MSI 4.5 can help you solving issues you are facing in your install project. But be aware that MSI 4.5 only supports Windows XP SP2,Windows Server 2003 SP1, and higher. Also watch out for the reboot requirements and silent install problems for the MSI 4.5 engine on Windows Vista.

Install and test the beta runtime

First a note fo caution: You should not install the SDK and runtime files on your production or develoment machine! In previous betas this happened to beak the build system. But when testing your msi setup - typically in a virtual machine - you could also use the MSI 4.5 engine. Once MSI 4.5 is released this is a must, because your msi file may be launched on a machine with MSI 4.5 installed, even if you don't redistribute this version with your setup. But it's also useful to test the beta version of the MSI 4.5 engine and report any issues to Microsoft (via the Connect site) so they may be fixed in the release version.

Add flags to your pre-4.5 packages

Windows Installer ignores tables, columns, flags and properties it doesn't know. Therefore MSI 4 packages today work with the MSI 2.x or 3.x runtime - of course without the new functionality. Similarly you can add flags that are new in MSI 4.5 ahead of time, to leverage the new functionality once MSI 4.5 is released. While in many cases this may not make much sense, there's one flag that I think should be set by default in all new msi setups: the msidbComponentAttributesShared attribute in the Component table. It prevents the downgrade of files that are shared across products. Without this flag, uninstalling a patch could downgrade such a file, thus breaking the other product. Read more about Shared Components Robustness in Heath Stewart's blog.

Note that adding not-yet-supported flags to your msi file will result in validation errors, so you should not do this if you plan to submit your product for logo certification before the release of MSI 4.5.

Think ahead when creating operating system conditions

stefan — Sat, 26 May 2007 09:33:00 GMT

There's a pitfall that I see people falling into from time to time: operating system conditions. Such conditions can be useful as launch conditions to enforce system requirements or used with features, components or custom actions to install different versions of files or run actions depending on the Windows version.

If the developer tells you that the application will run on Windows XP SP2, Windows Server 2003 and Windows Vista, you could create a launch condition like this:

(VersionNT=501 And ServicePackLevel=2) Or (VersionNT=502) Or (VersionNT=600)

But that’s probably not what you really want, because your setup would be blocked on XP SP3 (which is expected to be released later this year), on Windows Server 2008, and in general on any future version of Windows. In my opinion you should only block if you are sure that your application will not work on these Windows versions (unless of course you have a business model of charging your customs again for the same piece of software with the condition removed <wink>).

In general I guess your system requirements actually are: Runs on Windows XP but requires at least SP2; runs on Windows Server 2003 or Vista or any future version of Windows. That results in the following condition:

(VersionNT=501 And ServicePackLevel>=2) Or (VersionNT>=502)

Note that VersionNT is 501 for XP, 502 for Server 2003, and 600 for Vista. On Windows Server 2008 it might also be 600 but I wouldn’t count on that. If necessary you can differentiate client and server versions using the MsiNTProductType property.

The Windows SDK lists all the predefined operating system properties and also has a reference table of OS versions and property values.

Here’s a trick if your conditions tend to become complex, unreadable and hard to manage, for instance if they additionally involve the operating system language. Use custom actions of type 51 (“set a property”) to set properties with intermediate results and use those to build your final condition.

A reminder in case you’re using operating system conditions on components: make sure to set the msidbComponentAttributesTransitive flag in the Component table, in case users update their operating system; in InstallShield this means switching the Reevaluate Condition setting of the component to yes.

I’ll close with a general recommendation for launch conditions (not for component conditions!): Either condition the LaunchConditions action with “Not Installed” in all sequences (InstallShield does this for you by default), or append “Or Installed” to your conditional expression. This ensures that your setup can be uninstalled even if the machine no longer meets the system requirements, maybe because a prerequisite software has been removed.

Beware of the UAC Prompt Timeout

stefan — Wed, 18 Apr 2007 17:01:00 GMT

Recently I encountered a strange problem when I tried to install an MSI based setup on Windows Vista. I ran through the dialog sequence and clicked the “Install Now” button. The progress bar dialog was displayed as usual, and I left the computer to get a cup of coffee, expecting that the software would be successfully installed when I return.

But to my surprise on my return I was greeted with the “Setup was interrupted before the software was installed” dialog. In the log I found the following entries:

MSI (s) (00:B8) [15:02:24:944]: MSI_LUA: Elevation required to install product, will prompt for credentials
MSI (s) (00:B8) [15:04:59:002]: MSI_LUA: Credential Request return = 0x800704C7
The operation was canceled by the user.
MSI (s) (00:B8) [15:04:59:052]: MainEngineThread is returning 1602

MSI error 1602 means “User cancelled installation” and error code 0x800704C7 translates to “The operation was canceled by the user”. But of course I did not cancel the installation. Michael Urman of Macrovision helped me to understand what was going on, and I was able to reproduce the problem - without coffee ;-)

Some time after the progress bar dialog was displayed, the UAC consent dialog came up and asked me if I wanted to proceed. After two minutes of waiting, the UAC dialog disappeared automatically and the setup was cancelled.

So the UAC Prompt has a 2 minute timeout after which the operation is cancelled automatically without user interaction. This timeout, which I didn’t find documented anywhere, applies to other UAC prompts as well, like control panel actions that require elevation etc.

Unfortunately the return code 0x800704C7 doesn’t indicate whether the operation was cancelled by the user or by the timeout.

Note that there actually was that UAC shield icon on the “Install Now” button, but it was too subtle to make me wait for the UAC dialog. In my tests I have seen delays of more than one minute after the Install Now button was pressed until the UAC dialog came up.

I contacted the Windows Installer team at Microsoft about this problem. Tyler Robinson, the Lead Program Manager, told me that both the MSI team and the UAC team are aware of the issue, but they don’t have a solution at this time. He identified two main factors that are causing the delay:

System Restore. For compatibility reasons the restore point for the setup is created before the UAC prompt is displayed. Turning off system restore can speed things up.
Digital signature verification. UAC has to verify the digital signature of the msi package because the UAC dialog has a different banner color and text for setups that have a valid digital signature, as described here. Depending on the size of the .msi file this verification can take a while.

So if you have users complaining that the setup failed unexpectedly on Vista, ask them whether they saw the UAC dialog.

7 Reasons Why your Installations May Fail on Windows Vista (And How You Can Fix Them)

stefan — Wed, 07 Feb 2007 13:34:00 GMT

An article that I've written for the December 2006 issue of the Macrovision DevLetter.

7 Reasons Why your Installations May Fail on Windows Vista (And How You Can Fix Them)

Windows Installer is not just a technology but also a set of rules and best practices. While these rules have been specified in the SDK for several years, many of them haven't been enforced. While ignoring these rules didn't break your setups in the past, installations that don't follow best practices may eventually fail on Windows Vista™. This article alerts you to the most common pitfalls in setup authoring and helps you troubleshoot your installations to be compatible with Windows Vista.

http://www.macrovision.com/company/news/newsletter/tips/is_vista.shtml

Updated link to the Flexera Software web site:
http://www.flexerasoftware.com/webdocuments/PDF/is_vista.pdf

Launching a program when setup is completed may be a security issue

stefan — Fri, 22 Dec 2006 07:53:00 GMT

An article in the InnoSetup knowledge base points out that launching your application or displaying a readme file (using notepad for instance) at the end of your installation may cause a security issue on Windows Vista. The problem arises if the installation runs with elevated privileges because the child process (your application or notepad) inherits these privileges. This means that now your application runs with full administrator rights, which defeats the purpose of UAC.

This is a problem for all setups that don't use Windows Installer technology, like InnoSetup or InstallScript projects in InstallShield. But MSI based setups can also be affected.

If you launch an .msi file (by double clicking or via msiexec.exe) on Windows Vista, only custom actions that are scheduled for deferred execution in system contect (i.e. with the NoImpersonate flag set) will run with elevated privileges. Ususally you wouldn't launch your application with such an action, but instead use a DoAction event on the Finish button on the "setup complete" dialog. In this case you're fine.

However if you launch your MSI install using a setup.exe which is not explicitly manifested to indicate that it doesn't need elevated rights, the UAC prompt will be displayed right at the start, and your whole user interface sequence will run with elevated permissions. In this case the launched application will inherit these permissions.

In general it may be best not to launch the application at the end of the installation. Note that similar security problems can also happen on Windows versions before Vista, for instance if the setup was launched using RunAs with administrator privilges. And if a reboot is required to complete the installation, your application may not run properly when launched from the Finish dialog anyway.