About Windows Installer, the .NET Framework, and Visual Studio.
Windows Installer is an engine for performing transactional installations. When installing a product for the fist time, most often few or no files to be installed are already present on the machine. But when upgrading or patching a product, most often those files are replaced so copies must be kept if an error occurs and the installation needs to roll back. The following describes where and why Windows Installer may require so much disk space.
A bootstrap application may be required for a number of reasons. A bootstrap application may compressed setup files into the bootstrap application, or they might all be included in a self-extracting archive. Bootstrap applications may also download files from a web site either directly to a location on disk or indirectly to the Internet files cache.
This location is typically under %TEMP%.
If the extractor did not delete these files, you can delete these files after installation has completed. Note that some installers may register these files as a source cache. If the source cache is deleted and source is required for any reason, Windows Installer may prompt for the installation source or simply fail to reinstall the product.
If a full user interface is authored in a package and is to be displayed, Windows Installer creates copies of the .msi or .msp files in the user's %TEMP% directory. If this portion of installation - the client installation - was elevated, the %TEMP% location is for the user who authenticated and authorized the installation. Windows Installer uses this copy for initial disk space costs and through the UI phase until the installation script is to be generated.
This copy is in addition to any temporary copy that might have been extracted to the local hard drive. That is, the package that is referenced using msiexec.exe or in a Windows Installer API call is copied to %TEMP% with a Windows Installer-generated file name even if the source copy already was in %TEMP%.
This location is under %TEMP%.
If Windows Installer did not delete these files, you can delete these files after installation has completed.
Whether or not a user interface is displayed, the primary portion of the installation - the only portion that should attempt to modify machine state - runs as a service. At this point, the package - either a .msi file stripped of any embedded cabinets, or an entire .msp file - is copied to the Windows Installer cache under %WINDIR%\Installer. If the installation is successful, this file will remain in that location for all future maintenance installations including uninstalling the product. Patch packages are cached in whole to make available any updated files for future maintenance installations like repairs or installing additional patches.
This location is under %WINDIR%\Installer.
These files cannot be deleted or future maintenance installations on products - including even uninstalling a product - will fail.
There are two primary phases for Windows Installer: generate an installation script, then execute the installation script. But because Windows Installer is a transactional installation engine, unless rollback is disabled using either the DISABLEROLLBACK property or DisableRollback system policy a second script for rolling back the installation is generated.
These scripts contain all the operations that Windows Installer will perform when the script is executed. The rollback script is essentially those operations in reverse order. These scripts can grow quite large and are typically dependent on the overall size of a product. As an optimization, Windows Installer will typically not repeat file system directory and registry keys but will instead call SetTargetFolder or RegOpenKey opeations respectively, which set the scope for subsequent file or registry value operations. Custom actions can schedule similar operations to reduce disk space as well.
These scripts are created in C:\Config.Msi where C: is the fixed drive with the greatest amount of space available and is not necessarily the system drive.
These scripts must not be deleted. Windows Installer will delete them when an installation completes, even if an installation spans multiple reboots.
When the installation script is executed, if any files are to be copied or registry values written these resources will require space on the hard drive. Windows Installer will calculate how much space is required when the CostFinalize action is executed.
These resources are located wherever authored or the end user selected as the target location.
These resources should not be deleted; they comprise the product that has been installed and will likely prevent the product from starting up or functioning correctly. If any resources are deleted, you can repair the product from Add or Remove Applications control panel applet.
Because Windows Installer is a transactional installation engine, when existing files will be overwritten Windows Installer creates backup copies of those files. These files are created in a temporary directory along with the installation scripts. They are not compressed and will require as much space as those files required before being updated. Rollback files are more commonly created when products are patched, but are not limited to patch installation. Any product can upgrade files for another product, and should do so as shared components.
These resources are copied to C:\Config.Msi where C: is the fixed drive with the greatest amount of space available and is not necessarily the system drive.
These files should not be deleted. Windows Installer will delete them when an installation completes, even if an installation spans multiple reboots.
Windows Installer 3.0 added support to uninstall patches and to provide a more robust experience for applying binary deltas to existing files without accounting for every possible state an existing file could be in. That is, if a patch were to update foo.dll v1 to foo.dll v2 using a binary delta applied to foo.dll, the patch would have to account for foo.dll v3 or even having been updated by another product installation, or the installation would fail.
To make either of these features possible, Windows Installer copies files to be updated to the baseline cache under %WINDIR%\Installer\$PatchCache$ for each product. At most, there might be two copies of files created since Windows Installer retains a copy of the original (RTM) file and the latest minor upgrade (often distributed as "service packs") when either version of a file is initially replaced.
Since Windows Installer only copies a file to be updated to the baseline cache if the file will be overwritten, a baseline cache for a file might only exist for one product even if updated by a patch for multiple installed products. This can lead to source media requirements when some products are updated. Windows Installer 4.5 provides a feature to fix this by copying shared files to all products' baseline caches that installed those files - thus increasing disk space consumption. This improves servicing scenarios but at the cost of additional disk space.
These files are located under %WINDIR%\Installer\$PatchCache$ in a per-product location.
These files can be deleted or the baseline cache disabled using the MaxPatchCacheSize policy but when uninstalling a patch or when restoring missing files you will be prompted for source if a user interface is displayed; otherwise, the installation attempt will simply fail.
To complete the list above, could you please comment on who creates %WINDIR%\Downloaded Installations and how is this folder handled?
Apparently non-privileged user still get MSIs downloaded into this folder, even if normally such users can't change anything under %WINDIR% path.
Tony, that location is the default extraction location for InstallShield installers. It would fit under the heading "Extracted Files". It writes to this location by default - which requires elevation on Vista and newer - but can be changed. Please see http://search.live.com/results.aspx?q="Downloaded+Installations"+site%3Acommunity.installshield.com for more information.
One thing to note about the Downloaded Installations folder is that all recent versions of InstallShield that were designed and tested to work with Vista use a different default path for the Downloaded Installations folder. The folder is typically now located in the launching user's AppData\Local folder instead of %WINDIR%, unless it is explicitly changed by the package author.
Josh, thanks for the information. Unfortunately that is broken for per-machine installs when another user is invoking a maintenaince installation. A way to solve this is by installing the source cache as part of the MSI itself, thus installing both the product and the source cache in a single atomic fashion. In this way, if doing a per-machine installation the source can - and most definitely should - go to a protected area. There are some potential pitfalls as you can't store the MSI's hash in the MsiFileHash table without invalidating that hash. Since you should never update this file, however, that shouldn't pose a problem.
A little news coverage on something called Midori, Forrester's comments/ response on Vista enterprise
Service Packs for VSTS/TFS do not only contain bug fixes, but quite a few nice new features as you can
Some customers are reporting that Microsoft Visual Studio 2008 SP1 is failing to install with the following
Wow. Just wow. That's so incredibly baroque.
Would perhaps transactional NTFS be able to simplify this?
Windows Installer 5.0 is shipping in Windows 7 as part of the operating system. To address the issue
Microsoft Visual Studio 2010 Beta 1 customers have been reporting that when they start Outlook or any
Nice explanation, even if outdated.
However, a bit unsatisfactory... baroque, as said someone above. And still alive.
For example, a detailed explanation of how each part of a zeppelin is carefully designed and assembled will not move me to buy one. I will prefer a car, plain or train. You may say, "but it's so finely designed...". Yes, but it's still a big zeppelin, so I don't want it.
I mean: This article seems a quasi-technical justification of the big amounts of cache that silently store in our Windows systems. You may say: It's necessary and well designed. However...
Windows (or Installshield apps) should ask and take care of what kind of user you are (like when you choose to be a Home User, Pro, Ultimate, etc):
1- A lazy user (please, do everything for me, I don't want to think, nor getting organized, so please cache massively).
2- An organized user (I keep all my Setup sources organized, so please don't obsessively cache everything. Ask me whe you need one).
3- An organized user, but foresighted (I keep all my Setup sources well organized, but I can lose them, so please let me choose where to store them!!!).
Did Windows assumed only option 1? Are there tools to implement 2) or 3)?