VS 2005 SP1 Requires a lot of Disk Space

VS 2005 SP1 Requires a lot of Disk Space

  • Comments 33

Quite a few beta customers have reported that the Visual Studio 2005 Service Pack 1 Beta install requires a lot of space. This is by design a feature of Windows Installer. The amount of space required to install the patch can be reduced but a lot of space is still consumed after the patch is installed.

Patches are cached in whole because when additional patches are installed or when the product is repaired while patches are already installed, those .msp files actually contain the source for those files being updated or added. Without the patch cached in whole a product repair would not have the files necessary to reinstall them. This accounts for some of the space required in the %WINDIR%\Installer directory. If you download the patch from the web and opt to run the patch from the source, your web browser may cache an additional copy in your browser cache. Saving to your system drive will also require this additional space, so saving to a network location or to a different drive is recommended.

When installing any patch with any level of UI, Windows Installer also creates a copy of the patch in the user's %TEMP% directory for the client (UI) portion of the installation. To reduce some of the space required to install the patch, install the patch silently like in the following example:

> start /wait VS80sp1-KB918525-X86-Beta-ENU.exe /quiet /L*v+ VS80sp1-KB918525-X86-Beta-ENU.log

Logging is only an option, but is recommended in case other errors do occur. Additional logging options for the native wrapper and msiexec.exe are also available. Please be sure to attach logs to any bug reports.

Additionally, because our patches utilize newer functionality on Windows 2000, Windows XP, Window Server 2003, Vista, and beyond to enable proper installation order and supersedence, a baseline cache of all files being replaced or patched is created for files installed with the RTM package, and whenever the latest service pack's files are replaced by a small update under %WINDIR%\Installer\$PatchCache$ for each product being patched. Our largest SKU is Visual Studio 2005 Team System, and 2,556 files are added or updated. The main Visual Studio patch targeting all non-Express and non-TFS SKUs contains 2,935 files. On one test system, 2,291 files were copied into the RTM baseline cache requiring a total of 1.25 GB. That's on top of the 394 MBs required to cache the VS 2005 SP1 Beta main patch in its entirety.

While not recommended, you can set a Windows Installer machine policy to disable or reduce the maximum size of the baseline cache. MaxPatchCacheSize is a DWORD value that sets the maximum percentage of disk space that can be consumed by the baseline cache. The default is 10%. Note that by disabling the baseline cache, patching products that use binary delta compression may require source media in order to install the patch.

Leave a Comment
  • Please add 2 and 3 and type the answer here:
  • Post
  • I find your blog very, very hard to read. What font are you using, Pain Inducer Sans Serif? I am literally getting a headache trying to write this comment. (No, I am not exagerating.) Please find out who created this font and make them fix it. Jonathan Allen grauenwolf@fisbonds.com
  • Jonathan, sorry about the headache. I recommend asperin and a trip to http://www.microsoft.com/typography/ClearType/tuner/Step1.aspx to use the online ClearType tuner. The font is Calibri, which is the Office 2007 default, followed by Verdana. It could be that your ClearType settings are optimal for display or aren't even turned on. In the former case, this can be a real eye sore. Running the tuner should help with that.

  • Why should I use ClearType for the sake of one font? Especially when it makes all the other fonts look worse? Have you looked at that link you sent? The ClearType image is fuzzy. I don't want my fonts to be fuzzy, I want to to be crisp and clear like in the Black and White image. I even tried the tuner, and it didn't help nearly as much as turning it back off. Though that makes me ask why I should need to "tune" my screen in the first place when it looked just fine before. I have found that deleting the Calibri fonts from my computer have resolved the issue. However, I should not have needed to resort to that. Please forward my comments to the appropriate department. Jonathan Allen grauenwolf@gmail.com (sorry, the first email address was mis-typed)
  • Jonathan, the point of the ClearType tuner is to "unfuz". The initial images are examples of both good and bad ClearType, but are only images. Steps 2 and 3, IIRC, are where you pick the best looking (i.e., most crisp) display to tune ClearType for your display.

    With ClearType turned off, the fonts may appear a little jagged but shouldn't look to bad.

    To determine if you have ClearType on or not, right-click on your Desktop, choose Properties, click the Appearance tab, then click the Effects button. To enable ClearType or anti-aliasing ("Standard") is the second option.

  • The font used looks ok to me with and without ClearType on.
  • In general I like ClearType even though it only really worked on fonts that are primarily Italian characters. (Or maybe other small alphabets such as Cyrillic and Greek too; I didn't try them.) On fonts such as MS Gothic it works on sizes larger than something around 18, which of course isn't practical for most controls where the standard size is 9. Anyway, I like ClearType when it works ... but that's just me. Recently I've read complaints by others where certain kinds of monitors or maybe certain kinds of eyes don't handle the appearance of ClearType the way the majority do. Just as some Microsoft products have options to allow left-handed operation or high contrast displays, it's pretty understandable why Microsoft products should have options to turn off ClearType. I'm not sure yet what to think about ClearType in Meiryo. The font is fatter than MS UI Gothic so less information fits on the screen. The effect of smoothing isn't what it should be. But someone seems to have found a workaround for that: http://drwatson.nobody.jp/gdi++/index.html Whether or not you can read the text, look at the image containing screenshots of two displays of text. Meanwhile I thought the font in this blog looked like Verdana.
  • Norman, thanks for commenting. ClearType can be turned off or on for the entire OS (you can also opt to use anti-aliases, or have both off). IE7 even lets turn ClearType off for font rendering in IE. I'm not sure how independent of Windows' setting this is.

  • > ClearType can be turned off or on for the > entire OS Welcome to the difference between theory and fact. The Windows Control Panel provides an option to turn it on or off for the entire OS. Parts of Windows (e.g. Internet Explorer) and applications (e.g. Microsoft Office) have been reported not to obey the option. One example doesn't count because Vista is still a release candidate. Windows Control Panel options for fonts partly do and partly don't obey the ClearType setting. Screenshot: http://www.geocities.jp/hitotsubishi/5728-001.png
  • Installing Visual Studio 2005 SP1 Betaon Vista RC1 sounds like a common task until you figure out the

  • Patch installation scenario as I saw it:

    1) Unpack to %temp%\SOMENAME

    2) Copy to %temp% {Why??}

    3) Copy to %windows%\Installer {Again? Ok}

    4) unpack to %windows%\Installer\PatchCache

    The worst package I saw was DirectX SDK:

    1) There is HUGE zip

    2) Inside there is HUGE exe

    3) Exe unpacks CABs

    4) CABs install ZIPs

    5) in ZIPs there are samples.

  • This behavior is hideously inefficient and optimizes for the wrong case. Why would I want to constantly double or triple the installation footprint in order to optimize patching/repair, which I only do when new Visual Studio service packs come out, i.e. every couple of years. I wouldn't mind pulling out installation media for this rare case if it meant Visual Studio didn't take five times what Setup says after I install three service packs to it.

  • Fduch, as described in this post Windows Installer controls writing to %TEMP% and %WINDIR%\Installer. This is for UI and the actual installation, respectively. The location in %TEMP% is temporary and is created in %TEMP% for security and LUA purposes (normal users can't write to %WINDIR%\Installer). Because both msiexec.exe and MsiInstallProduct() require the path to a file, our wrapper has to extract the file. Windows Installer does not use this path and will copy to %TEMP% anyway. This file we extract will also be removed after installation completes (or an error occurs).

    You can avoid the copy in %TEMP% by running silently as described above.

    Phaeron, Windows Installer caches the patch for several reasons. In the case of VS, if you were to install and later remove a hotfix that targeted SP1, those source files for SP1 would be required and those are found in the SP1 patch. Thus, it is required to get the SP1 files to replace back onto your disk.

    The $PatchCache$ location is meant for binary deltas which we currently cannot use for VS, and you can disable that during SP1 install using the MaxPatchCacheSize policy also described in the post.

  • What about the config.msi directory?

    My Temp dir is on a different drive where there is enough space.

    But the installer creates a directory c:\config.msi and thats why it needs double the

    amound during installation on my sysdrive.

    Why isn't this directory below %temp%?

  • Okay, but again, this is optimizing for the exceptional case. Hotfixes are temporary fixes that are only supposed to be installed on afflicted systems, so they should hopefully be rare. What Installer should be doing is what RCS systems do, which is to backup only the updated files. The user should also have the option not to save uninstall information.

    Given this existing behavior, is it at least possible to slipstream the patch onto installation media so new installations don't have this overhead?

  • Frank, the C:\Config.msi directory (on the system drive) is for temporary copies of files (rollback files) in case an error occurs. These are the files being overwritten.

    Frank and Phaeron, these copies of files are controlled and created by Windows Installer and there is no setting to turn them off - besides the baseline cache copy using the MaxPatchCacheSize.

Page 1 of 3 (33 items) 123