One of the most-reported feedback issues with Visual Studio 2005 Service Pack 1 Beta is about how long it takes to install. There are, unfortunately, a couple things that account for this and currently nothing we can do to prevent them. We have been considering options to at least inform the users what to expect when installing VS 2005 SP1, and I can tell you how you can decrease the amount of time it takes to install the patch.

As described in How Patching Works, a Windows Installer package is really just a relational database processed by a runtime, and Windows Installer patches contain transforms that change the in-memory view of that database and cause a product repair – either full or partial, depending on options passed during maintenance installations when the patch is applied. Considering that, patching a product and doing a full product repair or installing a patch that causes a full product repair (because it touches files in every feature) can take as long as installing the original product. VS 2005 SP1 does patch files in just about every feature, so it will take a while to apply.

However, there is another problem that exacerbates the amount time it takes to install such a large patch. Because VS 2005 SP1 is so large, it takes a long time – typically around 10 minutes – to load the entire image into memory in order to generate a hash over the image. This is done as part of a SAFER check that Windows Installer always performs to verify that a package can be installed. Take a look at a snippet of the verbose log generated while patching Visual Studio 2005 Team System – our largest SKU – with the VS 2005 SP1 main patch, which targets the non-Express, non-TFS Visual Studio SKUs for a single language:

MSI (s) (58:40) [04:28:57:387]: SOFTWARE RESTRICTION POLICY: C:DOCUME~1userLOCALS~1TempZNW2EAVS80sp1-KB918525-X86-Beta-ENU.msp has a digital signature
MSI (s) (58:40) [04:36:33:562]: SOFTWARE RESTRICTION POLICY: C:DOCUME~1userLOCALS~1TempZNW2EAVS80sp1-KB918525-X86-Beta-ENU.msp is permitted to run at the ‘unrestricted’ authorization level.

Over seven and one half minutes is spent mapping the entire file into memory and generating an image has over the mapped file. That log was generated on a pretty fast machine, too, and times will vary depending on the machine. Note that this is in the server context, where the installation actually occurs. If you double-click the downloaded file, for example, and install the patch in any UI mode this cost is doubled, as both the client and server perform a SAFER check. The server check is necessary because it always runs, but doing this check in the client context alerts the user earlier in UI modes that the patch cannot be installed due to policy (or error, such as when the SAFER check fails due to insufficient contiguous memory).

To reduce the amount of time it takes to install VS 2005 SP1, you can install it silently and reduce the cost of the SAFER check. Our patch wrapper accepts any command-line arguments you could pass to msiexec.exe, so you can choose from a variety of means to install the patch silently, such as the following:

> 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.

Some have also noticed that the working memory set – hence memory requirements – are pretty hefty. The native wrapper is large and during extraction can require quite a bit of memory. Msiexec.exe which we shell out to in order to perform the install will also require a lot of memory during the SAFER check. Some spyware or virus scanning software will also attempt to load the file into memory, thus requiring additional memory. Temporarily disabling such software is recommended while installing large patches like VS 2005 SP1. Every package released from Microsoft goes through rigorous virus scanning and other checks before it is signed and published.

While there is nothing we can do about the time it takes through the SAFER check right now, there are things you can do documented above to reduce the time it takes. I am working on options for future products but really only the time through the SAFER check can be reduced. The time it takes to repair the product during patching installation and removal scenarios is proportional to the size of the product in terms of data to be written, and to how many files are patched.