About Windows Installer, the .NET Framework, and Visual Studio.
Visual Studio 2005 Service Pack 1 can take a long time to install and may apply to multiple products on your machine, appearing to install multiple times. This is a large service pack and installs a lot of files, fixing many issues and adding several new features to over 200 Visual Studio 2005 editions.
What follows is a detailed description of the Visual Studio 2005 Service Pack 1 installation experience – or any of our patches for .NET Framework 2.0 and Visual Studio 2005 – describing what is going on during various steps with links to more information and tips to save time and space. Throughout this example, the English Visual Studio 2005 Service Pack 1 for Standard, Professional, and Team editions – among some others – is used, which is by far the largest service pack package shipped to date.
Make sure that before installing the Visual Studio 2005 Service Pack 1 release, you uninstall Service Pack 1 beta if you have it installed.
The installation experience begins when you download the service pack. There are many service packs, split up for Visual Studio 2005 Standard, Professional, and Team editions; and for Visual Studio 2005 Team Foundation Services according to written languages. This optimizes patch size by sharing most of the files for each product in a single embedded cabinet within the .msp file. For Express editions, patch packages are split up for each project language, which optimizes patch size because most of the files are world-wide binaries across project languages resulting in smaller .msp files. Download whichever service pack packages are appropriate for which products you have installed in your environment.
Downloading the package locally will save a lot of time when invoking the patch, but saving the package to a network in appropriate environments makes it available to everyone without having to download it individually. In whichever Windows platform you install the service pack the executable must be mapped into memory when executed. On Windows XP and newer, a SAFER check is performed first to determine if the file can be executed, which also validates a digital signatures if a signature exists. All our patches are signed for customers' safety and security, so this check requires that the whole executable is read into memory in blocks or in whole. Currently, in Windows XP and Server 2003 the file is read in whole, so the more physical memory a machine has the faster this process will go. The more paging that is required, the slower this process will go. In some uncommon cases, this process may even fail, for which a workaround is available.
On Vista the file is read in blocks, and when validated will show the consent dialog as shown in Figure 1 if the patch wasn't already executed from an elevated shell. You won't see this dialog on Windows 2000, XP, or Server 2003.
Figure 1: Windows Vista Consent Dialog
Once you click Continue, the executable is executed. For smaller executables this is much faster because the executable can be scanned if necessary, and validated much faster.
On all supported Windows platforms, the patch wrapper must extract the embedded .msp file because all of the Windows Installer APIs and executables work on file paths. Our patch wrapper is responsible for enabling default logging, cleaning up logs upon success if no command-line parameters were specified or the Windows Installer Logging system policy was not set, and installing the patch on all applicable, installed products before requiring any possible reboots. During this process you'll see an extraction dialog as shown in Figure 2.
Figure 2: Patch Extraction Dialog
When extraction is complete, the patch wrapper will invoke msiexec.exe as an elevated process to install the .msp file to all applicable, installed products. The client process is elevated to mitigate some incorrectly authored custom actions in the original product .msi files.
If not running silently by passing /quiet to the patch wrapper – which means you wouldn't see any dialogs anyway – Windows Installer makes a copy of the .msp file in the user's %TEMP% directory because it is assumed to have write access to that location for user. It does this even though the patch wrapper extracted the .msp file to the %TEMP% directory already. This extra disk I/O is one reason it is worth installing the patch silently by passing the /quiet switch.
During the client installation portion, another SAFER check is performed on the .msp file itself, to provide the user with early indication that the patch package is invalid if that is the case. This is another reason it is worth installing the patch silently by passing the /quiet switch.
Because no dialogs are authored into the target .msi file nor added by the patch transforms, Windows Installer runs using basic UI mode as shown in Figure 3 and skips actions in the InstallUISequence table.
Figure 3: Windows Installer Basic UI
When the Windows Installer finishes processing in the client context, it transfers execution to the Windows Installer service to process the InstallExecuteSequence table. This results in the dialog as shown in Figure 4.
Figure 4: Windows Installer Basic UI during InstallExecuteSequence Processing
The service makes a copy of the .msp file in the %WINDIR%\Installer directory, which is the Windows Installer package cache. The .msp file is cached in whole because it provides the source for files to be patched and overwritten, and is required even during repair scenarios. Again a SAFER check is performed on this file to verify that is unaltered from the publisher. This SAFER check is performed because the client should not be trusted – which would otherwise lead to elevation of privileges – and because during silent installation the client would not have performed a SAFER check.
Installation continues by executing a custom action that prompts for confirmation about installing the patch as shown in Figure 5, followed by an End User License Agreement (EULA) for each patch being installed in the same transaction as shown in Figure 6.
Figure 5: Installation Confirmation Dialog
Figure 6: End User License Agreement Dialog
Windows Installer developers might be wondering why dialogs are shown in the execution sequence. The custom action is legacy code that used to guarantee patch installation sequence in Windows Installer 2.0 – as now supported in Windows Installer 3.0 and newer as a standard feature using the MsiPatchSequence table – followed by the installation confirmation prompt and the EULA dialog. The custom sequencing code has been removed, but the custom action's other purpose to present these dialogs has not. Using the msidbCustomActionTypeFirstSequence (0x100) custom action execution scheduling attribute means this should run during the UI sequence if the UI sequence was run, but since no dialogs are authored and Windows Installer runs in basic UI mode, the InstallUISequence table is not processed.
Windows Installer continues by determining feature and component state, as well as which files must be backed up to the baseline cache, in between the CostInitialize and CostFinalize actions. You can find the feature and component states in a verbose log during the InstallValidate action. This information is handy in determining what should be reinstalled during patch installation and what is actually going to be reinstalled.
Between the InstallInitialize and InstallFinalize actions, Windows Installer will generate a script as shown in Figure 7. This is what makes Windows Installer a transactional installer. While generating the execution script, a rollback script is also generated so that if the execution script fails the rollback script is processed.
Figure 7: Windows Installer Script Generation Dialog
After the script is generated when InstallFinalize is run (or any InstallExecute or InstallExecuteAgain actions, which we don't currently schedule), the script is executed as shown in Figure 8. It is during this time that backup copies of files are created in a hidden directory named Config.msi if they are in use and can be moved, backup copies of all files being overwritten or patched are copied to the baseline cache, and files in the .msp package are copied to their destination locations. That's a lot of disk I/O, so making sure you have closed all your applications can help, as well as disabling the baseline cache – understanding that by doing so source will be required to uninstall the service pack or other patch that targets files installed by the product .msi file.
Figure 8: Windows Installer Script Execution Dialog
When files must be copied out of a source location such as the original installation media or an embedded cabinet in an .msp file, an additional SAFER check is required to validate that each source package has not been tampered with.
Please note that during script execution the time remaining can be incorrect. This is often caused by custom actions that do not report back estimated time or actual progress, or because some custom actions may not be able to accurately estimate progress.
Once the execution script is finished, current patches will display a success dialog as shown in Figure 9.
Figure 9: Patch Success Dialog
If any other products are installed on your machine to which the patch applies, this process repeats starting after patch extraction. With Windows Installer, only one installation transaction for a single product can execute at a time, so even though a patch or patches may target multiple products they can only apply to a single product at a time. To help determine if you have multiple products installed to which a patch can apply, you can extract the .msp file by passing /extract to the patch executable you downloaded, optionally specifying a destination directory, and provide the path to that .msp file to the Patch Applicability Browser.
The larger the patch and the more files it installs, the longer the patch will take to install. There is a lot of disk I/O by design to support robust patching under Windows Installer, but there are workarounds you can use at your own risk to improve performance and decrease disk space required as documented here and in linked material.
Mike, keep in mind that the patch applies to multiple products, so the package you're being prompted for may not be, for example, VS. Check the dialog title and enable verbose logging so you can check in the log to see which ProductCode Windows Installer is acting on. You'll also find the ProductName in the log in a property dump at the end of the log.
I "installed" the service pack using the /quiet flag and it is no longer in my proc list (task manager). How do I know it is in fact complete and/or installed?
The wrapper (the EXE that you download) shells out to msiexec.exe for each installed product to which the patch applies and waits on each return code. So, if you don't see VS80sp1-*.exe in the task list anymore SP1 installation is complete. ou can verify this Visual Studio's Help->About box.
I made some more attempts... It failed again. I tried on a system with 1GB Ram and 7GB free diskspace. When runnig S80sp1-KB926601-X86-ENU.exe with the /quiet param I can watch in the taskmanager how its use of Ram increases, and when it reaches 200 MB it just exits. In the VS about box I can see that I'm still on the previous version. When I run it without the flag, then I can see the same behaviour in the taskmanager as described above, but the dialogbox with the progressbar freezes at the moment, when the 200 MB are reached. Install fails.
Oliver, you need to enable logging by passing "/L*vx patch.log" (without quotes) to the command-line when installing the patch in order to diagnose anything. Open a bug in Connect at http://connect.microsoft.com or contact Microsoft Support Services at http://support.microsoft.com.
I cannot uninstall sp1 beta, get
Trying to uninstall sp1 beta I get a 1706 error. After running for a half-hour, I get prompted for the VS CD. I point to my cd, but get
" Error 1706. An installation package for the product Microsoft Visual Studio 2005 Professional Edition - ENU cannot be found. Try the installation again using a valid copy of the installation package 'vs_setup.msi'."
I posted the issue on the connect site, no feedback yet.
When trying to install Visual Studio 2005 SP1 on Vista I get the following error:
"Error: 1305. Error reading from file C:\Windows\Installer\896fd56.msi". Verify that the file exists and that you can access it.
I checked and the file does exist. I tried to set the security for the "Everyone" to Full Control but still no luck. I can send the msi log file.
Do NOT change security under %WINDIR%\Installer. Windows Installer will wipe out the cache if the permissions allow anyone but SYSTEM and Adminstrators with full control. You will have to rebuild your installer cache. Read http://blogs.msdn.com/heaths/archive/2006/11/30/rebuilding-the-installer-cache.aspx for how to do that.
Along with that error should've been a system error code. Once you are able to rebuild the installer cache (or use msizap.exe TW! to clean it up, and reinstall VS 2005, which will likely be easier), if the error occurs again you'll need to look in a verbose log - created by passing "/L*v patch.log" to the patch EXE you downloaded, without quotes - for error 1305. The whole log line has a system error code (an HRESULT as a signed decimal) that reports more information about the error.
You must also install, patch, and uninstall VS 2005 as an administrator.
The dialog box now reports "Time remaining: 345 minutes". No Cancel button, no CPU useage, and its more than 2 hours since I started the SP1 installation. I guess my 3Ghz CPU with 2Gb of memory is to weak to install this service pack.
I dont even know what to do now? Hard-reboot the computer, and having to go through this pain again? Or wait and see if it succeeds, and if so, how long?
Ohh, its down to 344 minutes now.
What a joke!
My install aborted (ran out of disk space on C) and now it gets lots of errors every time i run it. It seems like the rollback was not successful. What options do i have now?
Adrian, read http://blogs.msdn.com/heaths/archive/2007/01/31/how-to-safely-delete-orphaned-patches.aspx for how to free-up space consumed by Windows Installer unnecessarily, and http://blogs.msdn.com/heaths/archive/2007/02/05/visual-studio-2005-service-pack-1-rollback-breaks-some-applications.aspx for how to fix VC if you run into errors documented in that post.
I'd really appreciate it if Microsoft could make it much quicker to install this SP. It is waaaay too slow, not acceptable when it comes from the biggest company in the world.
I cant be the only one with this problem surely...Although the SP1 install completed successfully, My debugging is completely useless in that I no longer get the unhandled exception information box anymore. All I get is ageneric "The application has encountered an error and needs to close..." error and the application exits. Does anybody know how to fix these please!! I can get no usefull error information whatsoever and fixing errors has become an impossible task.
Heath, to say that I concerned with this service pack is a huge understatement. We've decided to upgrade our development PC's with SP1 in an effort to remain secure and keep to Microsoft's best practice recommendations. However now I'm in a jam, we cant work because of the length of time (still) being consumed with this patch, we can't cancel because it seems to take just as long to cancel as it does to install the SP and now I have to explain why the lack of progress in my department. Now I know that you can't tell me anything different than anything listed in the above messages but you can't be serious in assuming this is acceptable to you VS communinty? Is there anything being done to resolve this? Is this the same team that brought us Windows OneCare? I'm not sure though because my OneCare virus scan only took 12 hours.
Shaf, please use the forums at http://forums.microsoft.com/msdn or file a bug against Visual Studio using Microsoft Connect at http://connect.microsoft.com.