Installing a Windows Installer product package requires a certain amount of space on disk, even if all the installation is doing is running a custom action. Besides file costing and other actions typically sandwiched between the CostInitialize and CostFinalize standard actions, Windows Installer will require space under %WINDIR%Installer to cache the .msi file, stripped of all cabinet streams in the primary storage object, which is the .msi file itself.

To roughly calculate the maximum space required for an installation, you need to take into account all the file sizes as well as the stripped .msi file that will be cached. Windows Installer itself uses a much more refined approach based on current machine state, but without re-implementing all the code Windows Installer executes, this is to get a rough idea.

If the product is being patched under Windows Installer 3.0 or newer, the files being patched are cached in a baseline cache for the RTM-level installation package. This helps reduce patch size. If a minor upgrade is installed a second baseline cache is created for the latest minor upgrade. While no more than two baseline caches will ever exist, if every file was patched this baseline cache would roughly be double the size of the installed file base.

But wait, that’s not all. The patches are cached in whole so that they can be properly sequenced into the view of the product so that when the product is then reinstalled the new information is used to patch files, add registry keys, etc.

In addition to all that, if you downloaded the .msi file and ran it from source, that .msi file is in your browser cache. If you run with a client user interface with more to display than the basic UI (/qb) a copy of the full .msi file is made in your %TEMP% directory.

I have written a script you can download to help calculate all this. Do keep in mind this is only a rough calculation of the space required. For a better idea of how much space is required, you might consider testing on a clean system – perhaps using virtualization to more quickly test different configurations – and comparing disk usage. Or you could dump the Component table after the CostFinalize action with a custom action such as my DumpTables custom action in the sample source I posted for determining which files are being patched. You’ll find quite a few non-persistent columns in the Component table, including many columns used to store costing information during the install session.

The sample script is not supported by Microsoft but please post any comments or questions here you might have.