VS 2005 SP1 Takes a While to Install

VS 2005 SP1 Takes a While to Install

  • Comments 36

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~1\user\LOCALS~1\Temp\ZNW2EA\VS80sp1-KB918525-X86-Beta-ENU.msp has a digital signature
MSI (s) (58:40) [04:36:33:562]: SOFTWARE RESTRICTION POLICY: C:\DOCUME~1\user\LOCALS~1\Temp\ZNW2EA\VS80sp1-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.

Leave a Comment
  • Please add 6 and 1 and type the answer here:
  • Post
  • What drivard is recommending means that if any errors installing the SP occur, it will be very difficult and most often impossible to determine why installation of the SP failed. Verbose logs are required to solve actual installation problems with the SP, so if you turn off logging to save 25 minutes and encounter a problem, you will have to re-enable verbose logging before the vast majority of problems can be diagnosed.

    Use caution and weigh your options carefully to consider whether saving 25 minutes (typically half the time to install SP1) is worth having to start over to enable verbose logging (so the typical 50 minutes plus the original 25).

  • You may be right that there is "nothing you can do to prevent" the insane time it takes to install..... Except, possibly patching in a more efficient manner. Or maybe even letting the user choose whether to perform that 20-minute hash check to begin with. I mean, I've installed quite a lot of 400+ MB patches that magically didn't take ages.

    Perhaps someone at Microsoft just need to rethink whether this is the correct way of applying a patch, instead of merely explaining away why it takes so long as "something we can't change"

    Just a suggestion. :)

  • So it takes ages to install on a machine with a amd 2400 installed not reccomeneded for laptops

  • Jesper, as explained in this post that 20 minute hash check is done unconditionally by Windows Installer itself, which is a runtime that processes and installs our patch. It can also be reduced to 10 minutes by running the patch silently, passing /quiet to the command line to the patch executable.

  • Heath,

    What Jesper is saying is: then don't use Windows Installer...find another method.

  • I'm also confused about why not releasing an updated VS2005 installer containing all those changes from SP1.  Imagine someone wanting to use VS2005 currently:  they'd have to wait an hour to install the original VS2005 and then another couple of hours to install the patch --- there goes their day and brain cells.

    Please, just make it easy, not hard...

  • I saw a suggestion not to attempt on laptop, well I do not have that luxury to decide where it goes. My primary development platform is on a laptop IBM R51, 1.5 GHz with only 512 Meg ram. What can I say, my company is poor.

    It took about 30 minutes to finally come up with the message "Preparing to install" and then another 15 minutes to tell me it can’t find the install package. That is now 40 minutes wasted. What I do not understand is that virtually no activity is showing in task manager yet the laptop is useless. Do MS hide the fact that their processes are using all the resources? All I can see is that the patch just consumes all the available memory nothing else.

    I am no on my second attempt and this time after 45 minutes the display changes to "Please wait while Windows configures MS VS 2005 team edition for software developers- ENU". Another 15 minutes later and I finally get a question "Do you want to install Yes/No". Maybe after an hour I do not want to install anymore. I suggest you just install, why ask me again. Now for the long wait to actually do the install. At least now I can see the CPU is running at 100%. I am rethinking our strategy to move to VS 2005, I think it is better to just stay with VS 2003. The whole reason for this upgrade is the hope that it will solve the "POOR" VS 2005 IDE performance. I can guarantee anyone that VS 2005 is definitely not a productivity booster. Please prove me wrong.

  • They could just have released .NET Framwork 2.0 and 3.0 addons for VS .NET 2003. It would have worked just the same. But instead they release a total new IDE with less to none new interesting features not possible as addons to VS .NET 2003.

    I can understand the need for an upgrade after VS 6.0, but not after .NET 2003.

  • I can say just one word for Saivert that don't know about the utility to update to VS 2005: "Edit and continue". Want anything else???

  • The upcoming Visual Studio 2005 Service Pack 1 can take a while to install and can require a lot of disk

  • Visual Studio 2005 Service Pack 1 can take a long time to install and may apply to multiple products

  • Heath Stewart has written several very useful blog posts about Visual Studio 2005 SP1 that I wanted to

  • Go get it here . Hopefully I'm not the first one to point this out to you. But better late than never.

  • There are several known issues when installing Visual Studio 2005 Service Pack 1 . I've documented these

  • There are several known issues when installing Visual Studio 2005 Service Pack 1 . I've documented these

Page 2 of 3 (36 items) 123