Like all major upgrades, Windows Installer adds features to at least each major version released. Windows Installer 2.0 added support for managed and Win32 assemblies, signed installer support, and much more over previous 1.x versions of Windows Installer. Windows Installer 3.0 added support for more robust patch sequencing, installing multiple patches at once, double-clickable patches, and more.
The version of Windows Installer supported on Windows 98 and Me is Windows Installer 2.0 but from my announcement earlier today you can see that the Microsoft .NET Framework 2.0 and Visual Studio 2005, at least, will require Windows Installer 3.0. The reason is that new features of Windows Installer 3.0 are being used on NT-based platforms, namely Windows 2000, XP, 2003, and newer. How is this done?
Windows Installer does a good job of being backward compatible. They accomplish this by triggering new features based on certain conditions. When describing how patches work, I mentioned that one such trigger for the more robust sequencing is the existence of the non-empty MsiPatchSequence table in the .msp file itself. Whether patches can be uninstalled — another new feature of Windows Installer 3.0 and newer — is whether the MsiPatchMetadata table is in the .msp file. Previous versions of Windows Installer will ignore standard tables that the runtime doesn’t know about.
With this in mind, you should set the database schema to the minimum version of Windows Installer required. Also, if you plan to install 64-bit binaries on a 64-bit machine you must set the schema to at least 200. New features will be lit-up based on other conditions, like the existence of certain tables. Future versions of Windows Installer with features that hinge on operating system features may be triggered simply by what operating system they are on.
When creating patches using PatchWiz.dll, you can have newer versions of PatchWiz.dll create patches that install on older databases, too. In your .pcp file, create a record in the Properties table named
MinimumRequiredMsiVersion and set that to the database schema you required, using, for example, 200 for Windows Installer 2.0, 300 for 3.0, and 310 for 3.1.