About Windows Installer, the .NET Framework, and Visual Studio.
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 signatureMSI (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.
Installing Visual Studio 2005 SP1 Betaon Vista RC1 sounds like a common task until you figure out the
I noticed that during the installer the CPU was running near 50% (hyperthreaded) for most of the install (about an hour). This is somewhat perplexing since there was very little disk IO (monitored occationally with filemon) during that time sounds like very inefficient processing going on before the actual install. I suppose this was the safer check listed here.
Also my logs were deleted after the install was finished as I just ran the EXE. :(
I noticed there was a period of time when there was no visual indication of anything happening apart from disk activity. Then later a progress bar that went to 100% done with zero minutes left, but it wasn't, it still went on for many more minutes. More accurate notification of progress would be nice.
Installing the patch took about 4 times more than to install VS2005 on AMD Athlon 64 3200+ with 2Gb of RAM.
Todd, the safer check does account for 20 minutes and there are other periods (not nearly as long) during the maintenance installation where Windows Installer reads the machine's current state (resulting in far less disk activity).
David, this period is most likely the native image generation and caching. This takes quite a long time and these custom actions - and most custom actions, really - don't report progress. This is a good suggestion for future products.
My mileage: 20 hours to patch just Visual C++ with code analysis on Pentium III, 1.5 GB of free disk space required.
"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".
Generating a hash is a sequential operation isnt it ? I.e. you dont need access to the entire image. Perhapes it be attempted in other ways - e.g. load parts of the image into memory at a time?
Digby, you're right and the bug was fixed in Vista to stream the image in blocks, but in XP and 2003 the entire image is loaded.
i'm trying to install the patch on windows vista, and have been waiting for more than 30 minutes but still the installer says preparing to install :-( .
Maulik, as explained here it will take a while because of various security checks. In Vista, the situation is even worse as the entire image is loaded into memory even before the UAC prompt, then mapped as necessary and the code executed.
In Vista where the bug described at http://blogs.msdn.com/heaths/archive/2006/08/23/Size-does-Matter.aspx is fixed so that the entire image isn't loaded into memory at once, it is still streamed in blocks and can possibly take as long.
There are a lot of fixes in this SP and so it is very large and will take a while to install.
- VS 2005 SP1 Tries to Install Multiple Times
- VS 2005 SP1 Requires a lot of Disk Space
- VS 2005 SP1 Takes a While to Install
As SP1 touches every file....
Simple solution, provide a new release, as the existing VS 2005 is crap anywa, so why bother trying to fix 100% of it..
Create a brand new install!!!
Not sure why this is not obvious...
After all this is exactly what MS did with vs 2002, vs 2003 is vs 2002 sp1!!!
If you are doing verbose logging, your install time will balloon. For example, our application normally takes 2-5 minutes to install. if we turn on verbose logging, that time blows up to 25 minutes or more, depending on the machine.
Turn off the logging and the times should drop considerably.