I have previously posted some instructions (here and here) that can be used to verify and attempt to repair the files that ship as a part of the OS on Windows Vista.  Since I wrote those posts, I have heard from a few customers who have attempted to use those instructions to repair their .NET Framework 2.0 and 3.0 files and/or Media Center files on Windows Vista, but received error messages from Sfc.exe indicating that some of the repair operations were not successful.

Fortunately, I recently found a Microsoft knowledge base article that provides more details about how to use Sfc.exe on Windows Vista, including steps that can be used to locate error messages and manually fix files that it was unable to repair.

You can find this knowledge base article at http://support.microsoft.com/kb/929833.  If you are running into problems with Windows Vista and suspect that some of the OS files may be corrupt or missing, I'd suggest trying out the steps in this knowledge base article to see if they help correct the issues that you are seeing.

I recently posted a set of instructions for creating an administrative install point for the .NET Framework 2.0 SP1.  In that post, I mentioned some behind-the-scenes architectural changes that affect how the installer works.  Those architectural changes were also made for the .NET Framework 3.0 SP1, and as a result, there is a new set of instructions that must be followed in order to create an administrative install point for the .NET Framework 3.0 SP1 as well.

The following are some steps that can be used to create an administrative install point for the .NET Framework 3.0 SP1 for each of the supported processor architectures.

Please keep in mind that there are several prerequisites that must be installed prior to attempting to deploy the .NET Framework 3.0 SP1 from an administrative install point.  These include the .NET Framework 2.0 SP1, MSXML 6.0, the RGB Rasterizer, the Windows Imaging Component (WIC) and the XML Paper Specification (XPS) shared components.  The .NET Framework 2.0 SP1 can be deployed using the steps in my previous blog post, and the other prerequisites can be deployed using the previously documented steps in the .NET Framework 3.0 deployment guide.  There is a new .NET Framework 3.5 deployment guide that is currently in the process of being published that will include this type of information, and I will provide an additional link to that document once it is available on MSDN.

To create an administrative install point for the .NET Framework 3.0 SP1 x86:

1. Download the .NET Framework 3.5 full package from http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe and save it to your local hard drive
2. Extract the contents of the setup package by running this command:
   
   dotnetfx35.exe /x:c:\netfx35
   
3. Stage the base MSI by running this command:
   
   msiexec /a "c:\netfx35\wcu\dotnetframework\dotnetfx30\netfx30a_x86.msi" TARGETDIR="c:\netfx30sp1\x86\AIP"
   
4. Apply the patches to the staged base MSI by running this command:
   
   msiexec /a "c:\netfx30sp1\x86\AIP\netfx30a_x86.msi" PATCH="c:\netfx35\wcu\dotnetframework\dotnetfx30\WCF.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WCS.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WF.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF1.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF2.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF_Other.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\XPS.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WF_32.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF2_32.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF_Other_32.msp"

With these steps, you will have an administrative install point for the .NET Framework 3.0 SP1 x86 located at c:\netfx30sp1\x86AIP.  You can then install the MSI directly using a command line like the following:

msiexec.exe /i c:\netfx30sp1\x86\AIP\netfx30a_x86.msi /l*v %temp%\netfx30sp1x86log.txt /qb VSEXTUI=1

You can adjust the parameters as needed if you want a fully silent install instead of basic UI, or want to use any other standard Windows Installer command line parameters.

To create an administrative install point for the .NET Framework 3.0 SP1 x64:

1. Download the .NET Framework 3.5 full package from http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe and save it to your local hard drive
   
2. Extract the contents of the setup package by running this command:
   
   dotnetfx35.exe /x:c:\netfx35
   
3. Stage the base MSI by running this command:
   
   msiexec /a "c:\netfx35\wcu\dotnetframework\dotnetfx30\netfx30a_x64.msi" TARGETDIR="c:\netfx30sp1\x64\AIP"
   
4. Apply the patches to the staged base MSI by running this command:
   
   msiexec /a "c:\netfx30sp1\x64\AIP\netfx30a_x64.msi" PATCH="c:\netfx35\wcu\dotnetframework\dotnetfx30\WCF.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WCS.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WF.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF1.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF2.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF_Other.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\XPS.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WCF_64.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WCS_64.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WF_64.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF1_64.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF2_64.msp;c:\netfx35\wcu\dotnetframework\dotnetfx30\WPF_Other_64.msp"

With these steps, you will have an administrative install point for the .NET Framework 3.0 SP1 x64 located at c:\netfx30sp1\x64\AIP.  You can then install the MSI directly using a command line like the following:

msiexec.exe /i c:\netfx30sp1\x64\AIP\netfx30a_x64.msi /l*v %temp%\netfx30sp1x64log.txt /qb VSEXTUI=1

You can adjust the parameters as needed if you want a fully silent install instead of basic UI, or want to use any other standard Windows Installer command line parameters.

<update date="1/23/2008"> Added example command lines to install the MSI directly after creating the administrative install point. </update>

I just noticed this post on Aaron Ruckman's blog and wanted to link to it here to help raise visibility.

Description of this issue

There is an issue in the XPS component that is a prerequisite for the .NET Framework 3.0, 3.0 SP1 and 3.5 that can cause each of these versions of the .NET Framework to fail to install on Windows XP and Windows Server 2003.  The XPS component can fail to install correctly if the Print Spooler service is not running on the system, and that in turn will cause the .NET Framework 3.0 or 3.5 setup to fail.  In most cases of this error that we've seen so far, an Visual C++ runtime error dialog appears during .NET Framework 3.0, 3.0 SP1 or 3.5 setup with the following text on it:

The application has requested the Runtime to terminate it in an unusual way.

This error usually occurs while the PrintFilterPipelineSvc.exe process is being run during the installation of the XPS component that is a prerequisite for the .NET Framework 3.0, 3.0 SP1 and 3.5 on Windows XP and Windows Server 2003 operating systems.  We have not yet heard of a case of this particular error affecting Windows Vista or later operating systems because the necessary XPS components are already present as a part of the OS, and therefore .NET Framework setup does not need to run PrintFilterPipelineSvc.exe.

How to work around this issue

If you are running into this issue on Windows XP and Windows Server 2003, you can resolve it by doing the following:

1. Click on the Start menu, choose Run, type services.msc and click OK
2. In the Services snap-in, locate the service named Print Spooler, right-click on it and choose Start

Note - if the Print Spooler service is already started and you are still seeing failures during .NET Framework 3.0 or 3.5 setup, then you are not running into this exact issue and your .NET Framework setup failure is being caused by some other problem.  In that case, I suggest consulting the .NET Framework setup troubleshooting guide for links to other possible installation issues and workarounds, links to log file locations, links to readme files, etc.

<update date="3/26/2008"> Added more details about the error message to hopefully make it easier to find this post when performing Web searches. </update>

The final releases of the Visual Studio 2008 Express Editions include an optional step to install Silverlight v1.0.   We have seen a few cases where the Silverlight v1.0 component fails to install during a VS 2008 Express Edition installation because a previous version of Silverlight v1.0 was already installed on the system.

Description of this issue

This scenario can occur if a pre-release version of Silverlight v1.0 is installed on the system and one of the following conditions is true:

• Automatic Silverlight updates are disabled on the system
• Automatic Silverlight updates are enabled, but you have not visited a Silverlight-enabled web site in a while (which will trigger the automatic update process)

How to diagnose this issue

In this scenario, the VS 2008 Express Edition setup log file (named %temp%\dd_install_*_xcor_90.txt) will contain an error message that looks like the following:

[12/12/07,12:12:12] ExpressUI: ***ERRORLOG EVENT*** : DepCheck indicates Microsoft Silverlight Runtime is not installed.

In addition, the Silverlight verbose MSI log file (named %temp%\SilverlightMSI*.txt) will contain error messages near the end of the file that look like the following:

MSI (s) (04:F4) [12:12:12:080]: Product: Microsoft Silverlight -- Configuration failed.

MSI (s) (04:F4) [12:12:12:081]: Windows Installer reconfigured the product. Product Name: Microsoft Silverlight. Product Version: 1.0.20816.0. Product Language: 1033. Reconfiguration success or error status: 1638.

MSI (s) (04:F4) [12:12:12:082]: MainEngineThread is returning 1638
MSI (s) (04:C8) [12:12:12:082]: No System Restore sequence number for this installation.
Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.
{89F4137D-6C26-4A84-BDB8-2E5A4BB71E00}

Windows Installer error code 1638 means that an MSI with the same product code but a different package code is already installed.

How to work around this issue

If you run into this type of error while attempting to install a VS 2008 Express Edition, you can work around it by doing one of the following:

• Visit http://www.microsoft.com/silverlight to trigger an automatic update to the latest version of Silverlight v1.0 if you have Silverlight automatic updates enabled
• Directly run the Silverlight v1.0 installer by downloading it from http://go.microsoft.com/fwlink/?LinkId=103103

This issue and workaround is also documented in the Visual Studio 2008 Express Editions readme.

A while back, I posted some instructions that can be used to create an administrative install point for the .NET Framework 2.0.  The .NET Framework 2.0 SP1 was recently released (it is required in order to install the .NET Framework 3.5).  There are some behind the scenes architecture changes in the .NET Framework 2.0 SP1 setup (which I'm planning to describe in more detail in a future blog post).  Those changes cause the previous instructions I posted for creating an administrative install point to no longer work.

Here are some updated steps that can be used to create an administrative install point for the .NET Framework 2.0 SP1 for each of the supported processor architectures.

To create an administrative install point for the .NET Framework 2.0 SP1 x86:

1. Download the full package from http://www.microsoft.com/downloads/details.aspx?FamilyId=79BC3B77-E02C-4AD3-AACF-A7633F706BA5 and save it to your local hard drive
2. Extract the contents of the setup package by running this command:
   
   netfx20sp1_x86.exe /x:c:\netfx20sp1\x86
   
3. Stage the base MSI by running this command:
   
   msiexec /a "c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\netfx20a_x86.msi" TARGETDIR="c:\netfx20sp1\x86\AIP"
   
4. Apply the patches to the staged base MSI by running this command:
   
   msiexec /a "c:\netfx20sp1\x86\AIP\netfx20a_x86.msi" PATCH="c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\ASPNET.msp;c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\CLR.msp;c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\CRT.msp;c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\NetFX_CA.msp;c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\NetFX_Core.msp;c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\NetFX_Other.msp;c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\PreXP.msp;c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\WinForms.msp;c:\netfx20sp1\x86\wcu\dotnetframework\dotnetfx20\DW.msp"

With these steps, you will have an administrative install point for the .NET Framework 2.0 SP1 x86 located at c:\netfx20sp1\x86\AIP.  You can then install the MSI directly using a command line like the following:

msiexec.exe /i c:\netfx20sp1\x86\AIP\netfx20a_x86.msi /l*v %temp%\netfx20sp1x86log.txt /qb VSEXTUI=1

You can adjust the parameters as needed if you want a fully silent install instead of basic UI, or want to use any other standard Windows Installer command line parameters.

To create an administrative install point for the .NET Framework 2.0 SP1 x64:

1. Download the full package from http://www.microsoft.com/downloads/details.aspx?FamilyId=029196ED-04EB-471E-8A99-3C61D19A4C5A and save it to your local hard drive
2. Extract the contents of the setup package by running this command:
   
   netfx20sp1_x64.exe /x:c:\netfx20sp1\x64
   
3. Stage the base MSI by running this command:
   
   msiexec /a "c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\netfx20a_x64.msi" TARGETDIR="c:\netfx20sp1\x64\AIP"
   
4. Apply the patches to the staged base MSI by running this command:
   
   msiexec /a "c:\netfx20sp1\x64\AIP\netfx20a_x64.msi" PATCH="c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\ASPNET_64.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\CLR_64.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\CRT_64.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\DW_64.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\NetFX_Core_64.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\NetFX_Other_64.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\WinForms_64.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\ASPNET.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\CLR.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\CRT.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\NetFX_CA.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\NetFX_Core.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\NetFX_Other.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\PreXP.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\WinForms.msp;c:\netfx20sp1\x64\wcu\dotnetframework\dotnetfx20\DW.msp"

With these steps, you will have an administrative install point for the .NET Framework 2.0 SP1 x64 located at c:\netfx20sp1\x64\AIP.  You can then install the MSI directly using a command line like the following:

msiexec.exe /i c:\netfx20sp1\x64\AIP\netfx20a_x64.msi /l*v %temp%\netfx20sp1x64log.txt /qb VSEXTUI=1

You can adjust the parameters as needed if you want a fully silent install instead of basic UI, or want to use any other standard Windows Installer command line parameters.

To create an administrative install point for the .NET Framework 2.0 SP1 ia64:

1. Download the full package from http://www.microsoft.com/downloads/details.aspx?FamilyId=32E77AE0-96EF-4ECD-A157-9BF61A7C8DAA and save it to your local hard drive
2. Extract the contents of the package by running this command:
   
   netfx20sp1_ia64.exe /x:c:\netfx20sp1\ia64
   
3. Stage the base MSI by running this command:
   
   msiexec /a "c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\netfx20a_ia64.msi" TARGETDIR="c:\netfx20sp1\ia64\AIP"
   
4. Apply the patches to the staged base MSI by running this command:
   
   msiexec /a "c:\netfx20sp1\ia64\AIP\netfx20a_ia64.msi" PATCH="c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\ASPNET_i64.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\CLR_i64.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\CRT_i64.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\DW_i64.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\NetFX_Core_i64.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\NetFX_Other_i64.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\WinForms_i64.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\ASPNET.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\CLR.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\CRT.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\NetFX_CA.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\NetFX_Core.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\NetFX_Other.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\PreXP.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\WinForms.msp;c:\netfx20sp1\ia64\wcu\dotnetframework\dotnetfx20\DW.msp"

With these steps, you will have an administrative install point for the .NET Framework 2.0 SP1 ia64 located at c:\netfx20sp1\ia64\AIP.  You can then install the MSI directly using a command line like the following:

msiexec.exe /i c:\netfx20sp1\ia64\AIP\netfx20a_ia64.msi /l*v %temp%\netfx20sp1ia64log.txt /qb VSEXTUI=1

You can adjust the parameters as needed if you want a fully silent install instead of basic UI, or want to use any other standard Windows Installer command line parameters.

<update date="1/23/2008"> Added example command lines to install the MSI directly after creating the administrative install point. </update>

A couple of weeks ago, I posted some notes about creating an installable layout for the .NET Framework 3.5 that can be used for network deployment or redistributable setup packages.  Since then, I've gotten a couple of questions about creating an installable layout for the .NET Framework 3.0 SP1.  Customers asking me about this have noted that there are full downloads available for the .NET Framework 2.0 SP1 and 3.5, but only a web downloader is available for 3.0 SP1 (all of these links are listed in this blog post).

To create an installable layout for the .NET Framework 3.0 SP1, you will have to manually download the set of packages that setup would ordinarily download on your behalf in the web download bootstrapper.  This set of packages can be determined by reverse engineering some of the 3.0 SP1 setup data files located in the .NET Framework 3.0 SP1 web download bootstrapper package.  The behind the scenes steps needed to interpret the setup data files are similar to previous posts I've written regarding assembling installable layouts (such as this one for the VS 2005 Express Editions).

Fortunately, Aaron Ruckman has created a table listing the exact packages and folder structure they need to be copied to in order to create an installable layout for the .NET Framework 3.0 SP1.  You can find this information in the blog post at http://blogs.msdn.com/aaronru/archive/2007/12/13/creating-net-framework-3-0-sp1-redist.aspx.

Just like with the .NET Framework 3.5, there are optimizations you can make to your installable layout depending on what scenarios you plan to support.  For example, you could choose to do any of the following:

• Leave out x64 packages if you will only be supporting x86 systems and vice versa
• Leave out .NET Framework 2.0 packages if you know that you will be running .NET Framework 3.0 SP1 setup on systems that already have the .NET Framework 2.0 SP1
• Leave out other prerequisites such as MSXML 6.0 if you know that the version being installed by .NET Framework 3.0 SP1 setup will already be present on the systems you support installing on

One important note that I've mentioned in the past, but that bears repeating here - if you decide to optimize your installer payload using any of the suggestions above, and it turns out that you over-optimized and setup really does need one of the packages that you deleted from the extracted folder, then .NET Framework 3.0 SP1 setup will attempt to automatically download the package for you if you have a live Internet connection during setup.  If it needs to download a package and the system does not have a live Internet connection, then .NET Framework 3.0 SP1 setup will fail to install.

If you are interested, there is also a more detailed description in this blog post about what the .NET Framework 2.0 SP1, 3.0 SP1 and 3.5 setup bootstrapper does behind the scenes and when it might trigger an attempt to download packages from Microsoft.

Since the final version of XNA Game Studio 2.0 was announced earlier today, we have heard from a few customers (notably, in the forum post at http://forums.xna.com/thread/36650.aspx) who have run setup and received a pop-up error message like the following while setup is trying to install the Games for Windows - LIVE Redist:

Source Required

Setup has detected that the original source is necessary to continue. Please redownload and execute XNAGS20_Setup.exe.

How to work around this issue

In the cases we've seen so far, this issue can be resolved by doing the following:

1. Go to the Add/Remove Programs control panel (or Programs and Features on Windows Vista)
2. Locate the item named Microsoft Games for Windows - LIVE Redistributable and choose to uninstall it
3. Re-run XNA Game Studio 2.0 setup

What is happening behind the scenes

XNA Game Studio 2.0 setup is failing in this scenario in the cases we've heard of so far because a version of the Microsoft Games for Windows - LIVE Redistributable was already installed on the system, but it was installed from a different source location than XNA Game Studio 2.0 setup is trying to use.  In this type of scenario, XNA Game Studio 2.0 recognizes that the Games for Windows - LIVE Redist is already installed and triggers a repair instead of an initial install.  If any of the files installed by this package are missing or corrupt, Windows Installer will try to find the source location in order to replace those files.  If the source location no longer exists, then XNA Game Studio 2.0 will display this type of error message.

The primary cause we've seen so far is a system that previously had the beta version of XNA Game Studio 2.0 installed and then uninstalled.  Behind the scenes, the same Games for Windows - LIVE Redist is installed by the XNA Game Studio 2.0 beta and the final release, but the source location was moved after the beta shipped.  Therefore, if any files installed by the Games for Windows - LIVE Redist are missing or corrupt, then the repair process for this package will trigger a request for the original source because it doesn't exist in the location that the final release of XNA Game Studio 2.0 installs it to.

However, this scenario will only occur if one of the files in the Games for Windows LIVE - Redist package is missing/corrupt and needs to be replaced.  That means that only a small subset of people who previously installed the XNA Game Studio 2.0 beta will ever see this error.  Most beta-to-final release install scenarios for XNA Game Studio 2.0 will work fine and not require any manual workarounds.

This scenario could also occur if some other product, such as a game that requires the Games for Windows - LIVE Redist, was installed on the system prior to installing XNA Game Studio 2.0.  The specific conditions that must exist to trigger this error message are the following:

• The Microsoft Games for Windows LIVE - Redistributable package must be installed on the system before running setup for the final release of XNA Game Studio 2.0, and must be installed from a source location that is different than the one used by XNA Game Studio 2.0 setup (which is %programfiles%\Microsoft XNA\XNA Game Studio\v2.0\Setup)
• One or more files installed by the Microsoft Games for Windows LIVE - Redistributable package must be missing, corrupt or an older version than the one in the package

Regardless of which setup originally installed the Games for Windows LIVE - Redist, if you encounter this error while installing the final release of XNA Game Studio 2.0, you should be able to resolve it by uninstalling this package from Add/Remove Programs and then re-running XNA Game Studio 2.0 setup as described above.

I have seen several reports of issues related to uninstalling a beta or release candidate build of Visual Studio 2008 and installing the final release.  As noted in many places, including this blog post, the most important step to take when updating a system to the final release of VS 2008 is to make sure that the pre-release VS 2008 packages are correctly removed.  There are a couple of different scenarios that have different sets of uninstall requirements that are worth clarifying here.

Updating from beta 2 to the final release

If you have the VS 2008 beta 2 build or an earlier beta installed, the uninstall process for VS 2008 includes logic to automatically chain the uninstall of any pre-release packages that it chained in during installation.  This means that if you had beta 2 installed, you can perform a very simple set of steps to remove beta 2 and install the final release:

1. Go to Add/Remove Programs and uninstall the item named MSDN Library for Visual Studio 2008 (if you chose to install it originally)
2. Go to Add/Remove Programs and uninstall the item named Microsoft Visual Studio 2008 <edition> Beta 2 - ENU
3. Go to Add/Remove Programs and uninstall the item named Microsoft .NET Compact Framework 3.5 pre-release (this package is one exception to the general rule that VS 2008 beta 2 uninstall will remove any other pre-release packages that it installed for you) 
4. Install the final release of VS 2008

If you follow these steps, you will probably notice that there will be several other packages that are left behind on the system after uninstalling beta 2.  However, each of those packages are designed to be automatically upgraded to the final release versions.  I've used theses steps on several systems (Windows XP, Windows Server 2003 and Windows Vista) and have had good results so far.  There may be some isolated cases where the pre-release bits end up interfering with the final release install, and in those cases it may be necessary to manually remove the remaining packages.  There is a link at the bottom of this post that lists all of the packages that are installed during VS 2008 setup if you need to uninstall them manually.

Updating from a post-beta 2 build to the final release

After VS 2008 beta 2, the chained uninstall feature was disabled within VS 2008 setup because a decision was made a while back to not automatically uninstall any chained components that are non-beta in case other applications on the system depend on them.

This means that if you have a post-beta 2 but pre-final release build (such as the release candidate), then you will need to make sure to uninstall all components by using the manual uninstall steps or the automated removal tool.  The order of uninstall is important in these uninstall steps, so make sure to follow them as listed in this MSDN topic if you choose to uninstall manually instead of using the automated removal tool.

One additional note here - the manual uninstall steps and the automated removal tool will also perform a full uninstall of the final release of Visual Studio 2008 if you need to remove that from your system as opposed to just removing a pre-release version of VS 2008.

A note about removing the .NET Framework 3.5 beta

The .NET Framework 3.5 setup package has a couple of features that allow you to directly upgrade a system from a previous beta to the final release.  For Windows XP and Windows Server 2003, the .NET Framework 3.5 is installed via a set of MSI packages.  Each of those MSI packages contains Windows Installer major upgrade logic to accomplish the beta-to-RTM upgrade scenarios.

On Windows Vista, the .NET Framework 3.5 installs the .NET Framework 2.0 SP1 (Update for Microsoft Windows (KB110806)) and the .NET Framework 3.0 SP1 (Update for Microsoft Windows (KB929300)) as OS hotfix packages instead of as MSI-based packages.  The final releases of these packages are designed to migrate forward any public beta versions of these packages so that you do not need to manually uninstall them, and I've successfully upgraded from beta 2 to RTM on several Vista systems without needing to uninstall these packages.  However, there have been a few cases we've run into where that logic does not work.

You can use the following steps to manually remove beta versions of the .NET Framework 2.0 SP1 and 3.0 SP1 on Windows Vista if necessary:

1. Go to the Programs and Features control panel
2. Click the link on the left side that is named View installed updates
3. Locate the item named Update for Microsoft Windows (KB110806), right-click on it and choose to remove it in order to remove the .NET Framework 2.0 SP1
4. When prompted to reboot, choose to reboot later
5. Locate the item named Update for Microsoft Windows (KB929300), right-click on it and choose to remove it in order to remove the .NET Framework 3.0 SP1
6. Reboot the system
7. Try again to install the final release of the .NET Framework 3.5

Useful VS 2008 beta uninstall links

Here are a few links that may be useful to you as you work through the process of uninstalling beta versions of VS 2008 and moving forward to the final release:

• Visual Studio 2008 uninstall instructions - http://msdn2.microsoft.com/vs2008/bb968856.aspx
• Visual Studio 2008 express edition uninstall instructions - http://www.microsoft.com/express/support/uninstall/default.aspx
• Link to download the Visual Studio 2008 release candidate and final version removal tool - http://go.microsoft.com/fwlink/?LinkId=105801
• Link to .NET Framework cleanup tool - http://blogs.msdn.com/astebner/archive/2007/12/04/6659905.aspx
• Visual Studio setup/installation forum - http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=26&SiteID=1
• .NET Framework setup/installation forum - http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1020&SiteID=1

As described in this post on the XNA team blog, the final version of XNA Game Studio 2.0 is now available for download.  Here are some links that are hopefully useful to help you get started using XNA Game Studio 2.0.

Download links

Here are download links for XNA Game Studio 2.0:

• XNA Game Studio 2.0 - http://www.microsoft.com/downloads/details.aspx?FamilyId=DF80D533-BA87-40B4-ABE2-1EF12EA506B7
• Project Upgrade Wizard for XNA Game Studio 2.0 - http://creators.xna.com/gamestudio2/UpgradeWizardSetup.msi

Installation instructions

Here are some links to help you get started installing XNA Game Studio 2.0:

• XNA Game Studio 2.0 installation instructions for new XNA developers - http://creators.xna.com/Education/newtoxna.aspx 
• XNA Game Studio 2.0 installation instructions for developers already familiar with XNA Game Studio Express 1.0 - http://creators.xna.com/Education/existingusers.aspx 
• XNA Game Studio 2.0 readme, including known issues and workarounds - http://go.microsoft.com/fwlink/?LinkID=97935

Getting started using XNA Game Studio 2.0

Here are some links to help you get started using XNA Game Studio 2.0:

• XNA Game Studio 2.0 getting started page on the XNA Creators Club web site - http://go.microsoft.com/fwlink/?LinkID=101280
• Overview of new features in XNA Game Studio 2.0 - http://creators.xna.com/Education/whatsnew.aspx
• How to use the Project Upgrade Wizard for XNA Game Studio 2.0 - http://go.microsoft.com/fwlink/?LinkId=104055
• XNA forums - http://forums.xna.com/

New samples and starter kits

The XNA Game Studio 2.0 getting started page also includes several new samples and starter kits to help you quickly learn about some of the key new features in XNA Game Studio 2.0.  Here are the currently available samples:

• Net Rumble starter kit - http://creators.xna.com/Education/StarterKits.aspx
• Audio 3D sample - http://creators.xna.com/Headlines/developmentaspx/archive/2007/01/01/Audio-3D-Sample.aspx
• Bloom post-process sample - http://creators.xna.com/Headlines/developmentaspx/archive/2007/01/01/Bloom-Postprocess-Sample.aspx
• Game state management sample - http://creators.xna.com/Headlines/developmentaspx/archive/2007/01/01/Game-State-Management-Sample.aspx
• Normal mapping effect sample - http://creators.xna.com/Headlines/developmentaspx/archive/2007/01/01/Normal-Mapping-Effect-Sample.aspx

Make sure to check back in the upcoming days and weeks for additional new content.

There are a couple of links that I want to post here in the hopes of making them easier to find for anyone reading my blog and searching for information about Visual Studio 2008 installation issues.  Both links contain descriptions of known installation issues and possible options that can be used to work around them.

VS 2008 Readme Files

Several known installation issues and workarounds are described in more detail in the Visual Studio 2008 readme.  This readme is located at http://download.microsoft.com/download/9/a/e/9ae0f6cc-7032-408e-9ca7-989f9e4af4ec/VS2008Readme.htm.

The following additional readme files may be useful depending on what version of VS 2008 you are attempting to install:

• VS 2008 Express Editions readme file - http://download.microsoft.com/download/9/a/e/9ae0f6cc-7032-408e-9ca7-989f9e4af4ec/VS2008ExpressReadme.htm
• MSDN Library for VS 2008 readme file - http://download.microsoft.com/download/d/6/b/d6b1f58e-6fc7-4d38-9e0f-aa2bcf7c9f1d/MSDNLibVS2008Readme.htm

VS 2008 Troubleshooting Guide blog post

In order to supplement the content in the readme, a colleague recently created a blog post that is being used to summarize some additional known issues that can be encountered while installing Visual Studio 2008 and steps that can be used to work around them.  If you are encountering VS 2008 installation issues and did not find any useful information in the readme, I encourage you to also check out the Visual Studio 2008 Troubleshooting Guide blog post at http://blogs.msdn.com/varungupta/archive/2007/12/04/visual-studio-2008-setup-troubleshooting-guide.aspx.

<update date="1/3/2008"> Added links to VS 2008 Express Edition and MSDN readme files </update>

Every once in a while, I hear from a customer who has encountered an error while trying to install Document Explorer 2005 or Document Explorer 2008 (which is a prerequisite component that is installed during Visual Studio 2005 or Visual Studio 2008 setup).

How to diagnose this issue

In those cases, I typically ask the customer to send me the verbose installation log file from Document Explorer setup, which is located at %temp%\dd_dexplore*msi*.txt in order to narrow down the cause of this error.  Then, I use the technique described in this blog post and search for the string "return value 3" to try to locate the action in the log file that indicates the root cause of the failure.

In many cases, Document Explorer setup failures end up with entries in the verbose MSI log file that look like the following:

12/01/07 11:11:11 DDSet_Status: BeginTransaction()->IHxRegisterSession::CreateTransaction() returned 8004036e.
12/01/07 11:11:11 DDSet_Error: BeginTransaction()->Attempt failed because another transaction was running.

More details about the cause of this issue

In most cases, this type of error means that a previous product installation was attempting to register a help collection, and something happened that caused that help collection registration to not complete correctly.

A customer recently posted a comment on one of my blog posts that describes this scenario in more detail.  To summarize that comment, if another help transaction is running, a file named C:\Documents and Settings\All Users\Application Data\Microsoft Help\Rgstrtn.lck (or C:\ProgramData\Microsoft Help\Rgstrtn.lck on Windows Vista) will likely exist.  If that file exists, it prevents other help collections from being registered on the system, and if a setup attempts to register a help collection during this time, it will fail with the type of error message listed above.

How to work around this issue

To work around this issue, you can reboot the computer (which will cause that file to be deleted in most cases), or you can manually delete the Rgstrtn.lck file to reset the state of the help collection installation system on your system.  After getting rid of that file, you can attempt to install Document Explorer again.

Note - this type of help collection installation error can occur in any product that includes help collections as part of their installation logic.  This error is not limited to Document Explorer setup.

The .NET Framework 3.5 is packaged as a core package that includes language-neutral binaries and English resources, plus a series of language packs.  The .NET Framework 3.5 setup has logic to detect the UI language of the OS it is being installed on, and to automatically chain in the installation of the appropriate language pack if one exists for that OS language.  However, there is a potential issue related to language packs that can affect .NET Framework 3.5 installation on non-English systems.  I've seen this issue reported by several customers and I want to try to explain what is happening behind the scenes and offer some options for working around this if you run into it on your system as well.

Description of the issue

As of the time that I'm writing this blog post, the .NET Framework 3.5 language packs have not yet been released for download.  As a result, if you run .NET Framework 3.5 setup on a non-English OS, it will attempt to download the language pack setup in the language that matches the OS language, but since they are not yet released, it will instead download a place-holder file and that place-holder file will fail to install because it is not a valid language pack setup package.  At the end of installation, the .NET Framework 3.5 setup UI will state that setup succeeded because setup treats language pack failures as warnings and not errors.  However, you may also see a warning or error as a result of this failed language pack installation even though the overall .NET Framework 3.5 installation process returns success.

In addition, if you attempt to use instructions like the ones listed in this blog post to create a network or CD install point for the .NET Framework 3.5, and then you run setup from that install point on a non-English OS that does not have Internet connectivity, setup will detect that it needs to download a .NET Framework 3.5 language pack (because it will not be able to find it in a relative path next to the main setup executable).  However, setup will fail to download the package due to the lack of Internet connectivity.  After setup completes, it will report that the .NET Framework 3.5 installation is successful, but will also display an error dialog that is caused by the language pack download failure.

How to diagnose the issue

In the case where .NET Framework 3.5 setup does not have Internet connectivity but detects that it needs to download a language pack, the log file named %temp%\dd_dotnetfx35install.txt will show error messages that look like the following:

[12/01/07,11:11:11] Microsoft .NET Framework 3.5LP - ESN: Cannot access file: C:\Documents and Settings\user\Desktop\netfx35\wcu\dotNetFramework\dotnetfx35\x86\dotnetfx35langpack_x86es.exe
...
...
[12/01/07,11:11:11] Microsoft .NET Framework 3.5LP - ESN: dlmgr: CDownloadJobBITSImpl::GetState(): TransientError
[12/01/07,11:11:11] Microsoft .NET Framework 3.5LP - ESN: dlmgr: Transient Error
Context: 5    Error code: -2145386480    Description: There are currently no active network connections. Background Intelligent Transfer Service (BITS) will try again when an adapter is connected.

The above is an example log file obtained by attempting to run .NET Framework 3.5 on a Spanish OS after copying the setup package to the desktop and disconnecting the network cable.

How to workaround this issue

Option 1 - control language pack chaining behavior with a command line switch

If you would like to prevent .NET Framework 3.5 setup from attempting to chain in any language packs during installation on a non-English OS, you can run setup with the following command line switch:

dotnetfx35setup.exe /lang:ENU

This is the syntax that Visual Studio 2008 setup uses when it chains the .NET Framework 3.5 so that it can ensure that .NET Framework 3.5 setup will not need network connectivity in order to install successfully.

One note - the /lang switch will not have any effect if you already have the .NET Framework 3.5 installed on your system.  It must be used during initial installation in order to cause it to skip downloading and installing any language packs.

Option 2 - download language packs and add them to your .NET Framework 3.5 layout

Alternatively, once the .NET Framework 3.5 language packs are released, you will be able to download their setup packages and place them in the dotNetFx35\x86, dotNetFx35\x64 and/or dotNetFx35\ia64 folder after following the instructions in this blog post to create an installable layout.  Doing this will prevent the .NET Framework 3.5 setup from attempting to download the language packs from the Internet if it detects that it needs to install one of them because the OS being installed on is set to use non-English UI.

Aaron Ruckman has posted a request for feedback on his blog at http://blogs.msdn.com/aaronru/archive/2007/11/30/looking-to-improve-the-visual-studio-user-experience.aspx.  He is looking for feedback regarding installation and deployment scenarios for Visual Studio in order to help make deployment scenarios for future versions of Visual Studio as useful as possible.

If you have feedback regarding the Visual Studio installation and/or deployment experience, I encourage you to take a look at the information in this blog post and provide your feedback in the form of an email to Aaron (his email address is in the text of the blog post) and/or comments on the blog post itself.  When possible, please include suggestions for improvements if you can think of any for the scenarios you are interested in.  Bug reports are useful too, but I also encourage you to report specific bugs on the Visual Studio bug reporting site and not only report them via email or comments on Aaron's blog post.

I've posted an updated version of the .NET Framework cleanup tool that contains the following changes:

• It is now able to remove the .NET Framework 2.0 SP1 beta and final release MSIs; it does not remove the .NET Framework 2.0 SP1 OS hotfix package on Windows Vista however
• It is now able to remove the .NET Framework 3.0 SP1 beta and final release MSIs; it does not remove the .NET Framework 2.0 SP1 OS hotfix package on Windows Vista however
• It is now able to remove the .NET Framework 3.5 final release (previously it only removed the beta versions)
• It includes some additional removal options to allow removing all versions of the .NET Framework that are not OS components on Windows XP Tablet PC Edition, Windows XP Media Center Edition, Windows Server 2003, Windows Vista and Windows Server 2008

In addition, thanks to a suggestion from a customer, I have added the readme and a change history text file to the zip file that contains the cleanup tool to make it easier to understand what the tool does, what changes were made, and whether or not you have the most recent version of the tool.

Please refer to the .NET Framework cleanup tool user's guide to find more information about the .NET Framework cleanup tool and download it if you need it on your system.

<update date="6/7/2010"> Fixed broken link to the cleanup tool. </update>

Back when the .NET Framework 3.5 beta 2 was released, I posted this item on my blog describing how to download the individual pieces of the .NET Framework 3.5 beta 2 in order to create an installable layout that can be used to create an installer that includes the .NET Framework 3.5 or for network deployment.  If you have looked at those instructions, you'll notice how long, tedious and potentially error-prone they are.

Fortunately, as Bret Grinslade noted in this blog post, in the final release of the .NET Framework 3.5, a new package is available for download that includes all of the pieces of the .NET Framework 3.5 so that you no longer need to download the pieces individually in order to assemble an installable layout.

The combined installation package for the .NET Framework is available for download at http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe.

After downloading this package, you can extract the contents by running dotnetfx35.exe /x and it will prompt you with a location to extract the contents to.  From there, you can trim down the installer payload if appropriate in your deployment scenario in the following ways:

• If you do not plan to support installing on Windows Vista at all or plan to require Windows Vista SP1 in your scenarios (which will include the .NET Framework 2.0 SP1 and 3.0 SP1 so they do not have to be installed separately), you can remove the MSU files in the dotNetMSP folder
• If you only plan to support installing on Windows Vista or later, you can remove the dotNetFX20 and dotNetFX30 folders.  These folders contain the .NET Framework 2.0 SP1 and .NET Framework 3.0 SP1 packages that are used on Windows XP and Windows Server 2003
• If you plan to only support specific processor architecture(s), you can remove the appropriate payload for the processor architectures you do not plan to support (ia64, x64 or x86)

Now you can run dotnetfx35setup.exe from the extracted folder to start installing the .NET Framework 3.5.

One important note - if you decide to optimize your installer payload using any of the suggestions above, and it turns out that you over-optimized and setup really does need one of the packages that you deleted from the extracted folder, then .NET Framework 3.5 setup will attempt to automatically download the package for you if you have a live Internet connection during setup.  If it needs to download a package and the system does not have a live Internet connection, then .NET Framework 3.5 setup will fail to install.