About Windows Installer, the .NET Framework, and Visual Studio.
There are several known issues when installing Visual Studio 2005 Service Pack 1. I've documented these below and, when possible, have included workarounds and status on any pending fixes.
Error 1718.File '...' was rejected by digital signature policy
Install Rolls Back and Breaks Applications like Live Messenger
Visual Studio 2005 Service Pack 1 Takes a Long Time to Install
Visual Studio 2005 Service Pack 1 Requires a Lot of Disk Space
Error 2908 – An Unexpected Error Installing the Package
Other Installation Errors
This problem occurs mainly on Windows Server 2003 Service Pack 1, and could potentially occur on Windows XP. It does not occur on Windows Vista.
Starting with Windows XP, a software restriction policy known as SAFER was introduced as a preventative measure to help avoid running unsafe files. Both Windows XP and Windows Server 2003 require enough contiguous memory to check files, and Windows Server 2003 seems to fragment memory more heavily leading to this error message. Windows Vista performs the same check, but uses far less memory. In most cases following the instructions documented in KB925336 will work, but we received reports where these steps did not work. Investigation into these cases suggests the steps failed because an Active Domain policy refresh overwrote the local SAFER policy.
While we continue to investigate fixes to Windows XP and Windows Server 2003 you can set a registry value to reliably install Service Pack 1. Follow the steps documented in the workaround for error 1718 to set the DWORD registry value named PolicyScope to 1 in the HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers registry key. If the registry value is not set you should set it, but if the domain policy updates your machine before each SAFER check is made while installing the patch you may still run into the same problem. Some people have confirmed that following the workaround steps allowed them to install Service Pack 1. Be sure to reboot your machine after both leaving the re-joining the domain.
Visual Studio 2005 Service Pack 1 for Standard, Professional, and Team editions is large – there are a lot of fixes in that package. Required disk space is calculated by Windows Installer when installing products and patches, and this task is not always accurate. Normally insufficient disk space means that Windows Installer displays one of several error messages depending on the circumstances. Whether a message is displayed or not, Windows Installer will roll back the installation. On Windows XP and Windows Server 2003, this may mean that the manifest files under %WINDIR%\WinSxS are removed. Any applications that depend on the VC runtimes in this directory will break. You can fix this issue by repairing Visual Studio 2005, either through Add/Remove Programs or by running setup.exe from your original installation media and choosing the Repair option.
This is another documented problem due in large part to the number of fixes included in the service pack. For Team Foundation Services and Express editions, both time and space required to install their respective service packs is minimal. You can mitigate some time by disabling the patch cache and running silently.
Our product and patches for Visual Studio and the .NET Framework – except on Vista as installed with the operating system – use Windows Installer. Windows Installer is a robust, transaction installation that requires a lot of data collection and a two-phase installation to support transactional installation. Because of this and the disk I/O necessary long installation times should be expected. Disabling the patch cache will reduce the amount of disk I/O.
You can further save time by installing the patch silently, which reduces the number of steps and an extra security check required to install the patch for each product to which the patch applies. To install the patch silently, on the command line pass /quiet to the patch executable:
Replace VS80sp1-KB926601-X86-ENU.exe with whatever file name you downloaded is appropriate. The file here is for the English Visual Studio 2005 Standard, Professional, and Team editions.
There are a lot of fixes in this service pack, and because of how Windows Installer caches patches a lot of disk space is required. Please make sure you have enough disk space to install the service pack as documented in the download page under "Installation Requirements".
Note that if you have multiple products installed for a particular patch, multiply the required space for that patch by the number of products installed on your machine for which a patch applies. This is the maximum amount of disk space required so it is a high estimate. A typical case is Visual Studio 2005 Standard, Professional, or Team Suite installed along with the Team Foundation Client and/or SQL Server 2005, since SQL Server 2005 uses the Visual Studio IDE that we package. If you're not sure what applicable products you have installed, extract the patch by passing /extract on the command line and use my Patch Applicability Browser, providing the extract .msp file you just extracted in the user interface.
This is another common issue related to the size of the patch and running out of disk space. Please free up some disk space as required for the patch and reinstall the patch. Note that because of the rollback, products that depend on VC may be broken until you repair Visual Studio 2005 or reinstall Visual Studio 2005 Service Pack 1.
Updated: Read Visual Studio 2005 Service Pack 1 Rollback Breaks Some Applications for more details.
There are some other known issues once the patch is installed that are documented in KB928957. You may also continue to read my blog or, more specifically, the VS 2005 SP1 tag where I will post more information about other issues that may arise and any updates to workarounds or fixes.
PingBack from http://blogs.msdn.com/heaths/archive/2007/01/11/known-issues-with-visual-studio-2005-service-pack-1.aspx
There's also a problem with Web Application Projects. I've seen quite a few posts out there of people writing about the same problem. I uninstalled the Web Application Project add-in, then I installed SP1 (which is supposed to have WAP built-in), and now when I try to open a solution with a WAP-type project in it, I get the error message "the project type is not supported by this installation".
Haven't seen a solution for it yet.
When I run VS80sp1-KB926601-X86-ENU.exe with /extract I get a 477 MB .msp file. Can I put that file on a distribution file share for others to install to save them the time of extracting, or is this file specific for the product(s) I have installed on my system?
Also, is this the file that Windows Installer tries to load in to memory to check the digital signature? If not, how big the file that causes this problem.
The "Installation Requirements" for SP1 mentions: "192MB of RAM required. 256MB or greater is recommended." How can this be sufficient if Windows Installer needs to read a big file in to memory to be able to verify the digital signature?
Can you explain why it needs to read the entire file in to memory, and why the memory needs to be unfragmented? As far as I know SAFER on Windows XP and Windows Server 2003 uses an MD5 or SHA1 hash, both of which operate on 512-bit blocks and can thus be calculated while reading a file in small blocks rather than having to load the entire file in to memory.
On my Windows Server 2003 SP1 system with 1 GB and without the policy workaround I have not been able to install SP1. Yesterday I added an extra 1 GB and had 1.6 GB of physical memory available after rebooting (which I did to minimize the chance that memory would be fragmented too much). You would think there should be enough unfragmented memory, but apparently this was not the case, as the installation failed once again with this error!
I have some suggestions:
- fix the digital signature check so that it doesn't need to read the entire file in to memory
If that is not possible:
- add a command line switch to disable the digital signature check for the current installation, rather than having to modify the Local Security Policy (which people may forget to reset after installing)
- make sure that Windows Installer reports that it does not have enough contiguous memory to verify the digital signature, rather than saying that the file was rejected by digital signature policy, which would suggest to most people that the file is corrupt. It caused me to re-download the file several times to make sure it wasn't.
My next attempt will be to slipstream an administrative image (from an XP machine) using your explaination in a previous blog posting, even though I don't like that this will cause all files to be unpacked. Hopefully there will be ISO images of slipstreamed builds on MSDN subscriber downloads soon (which Scott Guthrie mentioned in a comment on his blog: http://weblogs.asp.net/scottgu/archive/2006/12/15/visual-studio-2005-service-pack-1-sp1-released.aspx#1255232)
Can you please elaborate on the issue with rollback? Especially since Windows Installer does transactional installations, I would think that a rollback restores the system to the previous state, but you're saying that rollback causes manifest files in the WinSxS directory that existed before the installation to be deleted afterwards? That doesn't sound right..
Gerard, you should generally not install the extracted MSP. As documented in http://blogs.msdn.com/heaths/archive/2006/10/06/VS-2005-SP1-Tries-to-Install-Multiple-Times.aspx, the patch may apply to multiple products and needs to apply to each. The wrapper makes sure it does. You can put the EXE on a network share, but it will still make local copies as documented in http://blogs.msdn.com/heaths/archive/2006/10/06/VS-2005-SP1-Requires-a-lot-of-Disk-Space.aspx.
We've tested on systems with less than the recommended memory and it works because of virtual memory. On Windows Server 2003 there is often more fragmented memory so there is not enough contiguous memory for SAFER to work as designed and implemented on XP and 2003. Even though hash algorithms like SHA1 and MD5 are block algorithms, XP and 2003 read the whole file into memory while Vista streams it. This is also mentioned in several posts, including http://blogs.msdn.com/heaths/archive/2006/08/23/715558.aspx when I first mentioned this problem.
Adding physical memory won't necessarily help. How processes allocate memory matters.
We are working on getting a fix on XP and 2003 as mentioned in this post under the "error 1718" heading but risk is always a factor.
Any chance you can give us some guidance as to how and when we can dump the patch cache... I'm a little annoyed by the enormity of my cache for a while.
Regarding error 1718:
"Starting with Windows XP, a software restriction policy known as SAFER was introduced as a preventative measure to help avoid running unsafe files. Both Windows XP and Windows Server 2003 require enough contiguous memory to check files, and Windows Server 2003 seems to fragment memory more heavily leading to this error message. "
In other words, it would be better to reboot the machine with fewer programs/services running, especially W3P services or other activities likely to cause high virtual memory use, right? The longer the server runs, the more fragmented the virtual memory becomes, correct?
Would setting any of the HeapDeCommit-related registry keys on Windows Server 2003 to higher values help this? How high would be recommended?
Heath, I notice issues with Reporting Services in VS2005 (using ver: 8.0.50727.42) when using date parameters - when I click view report in the preview pane having entered 12/01/2007 (I'm all set up for UK date format), it changes the parameter to 01/12/2007 and the report shows 1st Dec instead of 12th Jan. If I click view report again, it swaps it around again and shows 12th Jan on the report. The Language settings on the report are set to English (United Kingdom), and if I actually deploy the report rather than previewing it, it works fine.
I have tried this on a number of machines and other people also seem to be experiencing the same problem. Is this something that is being fixed in VS 2005 SP1 or is it something being looked at if it isn't in SP1???
"Windows Installer is a robust, transaction installation"
"because of the rollback, products that depend on VC may be broken"
Todd, we have not explored options for dictating how and how much memory is allocated for processes. Rebooting with fewer services running may help, but is not absolutely going to fix the problem.
Chris, any problems related to how the products works (or doesn't) should be address in the appropriate MSDN forum (http://forums.microsoft.com/msdn) or via Microsoft Connect (http://connect.microsoft.com). I deal with the setup and servicing of the product.
Unbelievable, Windows Installer is a robust transactional installation engine - but like all things - custom code or wacky implementations can break that. Just as P/Invoke and certain types of faults can break managed apps, custom actions in Windows Installer or violating rules that ICEs would usually catch (they can't catch everything, especially in the case of custom actions) will break such features of Windows Installer. This is the case for the VC WinSxS assemblies in Whidbey.
"Windows Installer is a robust transactional installation engine - but like all things - custom code or wacky implementations can break that"
Made my day... So what's the wacky implementation? The original installation or SP1? :) Just teasing. I installed it in 3 machines without a problem.
>> In other words, it would be better to reboot the machine with fewer programs/services running, especially W3P services or other activities likely to cause high virtual memory use, right? <<
Since each process has its own virtual memory address space, reducing the number of processes should not have an effect on this (except that you may have performance improvement due to to less frequent swapping).
It seems to me that setting the boot.ini /3GB option might help, since it would increase the address space available to the process that performs the SAFER check, although that process would have to be be flagged as a /LARGEADDRESSAWARE application. Unfortunately, msiexec.exe does not have that flag set (WinXP SP2), and I assume that that's the process context that the SAFER check is happening in.
I wonder if using "editbin /largeaddressaware msiexec.exe" might help? Of course there would be System File Protection to deal with, not to mention venturing into completely unsupported and untested territory for MSI...
Probably best just to leave VS 2005 SP1 alone.
>> We've tested on systems with less than the recommended memory and it works because of virtual memory. On Windows Server 2003 there is often more fragmented memory so there is not enough contiguous memory for SAFER to work as designed and implemented on XP and 2003 <<
With the start of the New Year comes new updates and features in Visual Studio 2005 and Visual Studio
安裝 SP1. 有時候並沒有想像中的順利... Known Issues with Visual Studio 2005 Service Pack 1 Make sure u have read this
To misquote Juvenal' Satires:
"Who fixes the bugs in the bug fix install?"