Last week, I posted a set of command line parameters that can be used to repair or uninstall the .NET Framework 2.0 SP2 and 3.0 SP2.  When I was working on that blog post, I noticed a behavior change that is new in 2.0 SP2 setup and 3.0 SP2 setup that affects the repair scenarios for these products on Windows XP and Windows Server 2003, so I wanted to describe the issue and how to work around it.

Description of the issue

There was a change made in the MSI-based installers for the .NET Framework 2.0 SP2 and 3.0 SP2 that causes the default repair that happens when you use the Add/Remove Programs entry for these products to not actually repair anything.  For example, if you end up with an out-of-date version of c:\windows\system32\mscoree.dll or if any of the files or registry values in the .NET Framework 2.0 SP2 or 3.0 SP2 are missing entirely, the repair from Add/Remove Programs will not restore the files or registry keys.

Because this issue only affects the MSI-based installers for 2.0 SP2 and 3.0 SP2, you will only encounter this issue on Windows XP and Windows Server 2003.  On Windows Vista and Windows Server 2008, the .NET Framework 2.0 SP2 and 3.0 SP2 are installed as OS update packages instead of as MSIs.

How to work around the issue

If you need to repair the MSI-based version of the .NET Framework 2.0 SP2 or 3.0 SP2 on Windows XP or Windows Server 2003, you must run the following command lines instead of using the repair option from Add/Remove Programs:

.NET Framework 2.0 SP2 - silent repair

msiexec /fpecmsu {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REINSTALL=ALL /l*v %temp%\netfx20sp2_repair_log.txt /qb

.NET Framework 3.0 SP2 - silent repair

msiexec /fpecmsu {A3051CD0-2F64-3813-A88D-B8DCCDE8F8C7} REINSTALL=ALL /l*v %temp%\netfx30sp2_repair_log.txt /qb

Behind-the-scenes details if you are interested

There is a difference in the command line switches being passed in to trigger the repair of 2.0 SP2 and 3.0 SP2 compared to 2.0 SP1 and 3.0 SP1.  Here are a couple of specific examples:

.NET Framework 2.0 SP2 - silent repair

msiexec /fpecmsu {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REINSTALL=ALL /l*v %temp%\netfx20sp2_repair_log.txt /qn

.NET Framework 2.0 SP1 - silent repair

msiexec /i {B508B3F1-A24A-32C0-B310-85786919EF28} /l*v %temp%\netfx20sp1_repair_log.txt /qn

The reason that these command lines need to be different (aside from the product codes changing between SP1 and SP2) is that the REINSTALL=ALL property no longer gets set by default in the MSI-based .NET Framework 2.0 SP2 or 3.0 SP2 repair processes.  There is a custom action in .NET Framework 2.0 SP1, 2.0 SP2, 3.0 SP1 and 3.0 SP2 setup that sets the REINSTALL=ALL property during repair scenarios.  However, the condition for that custom action was changed in 2.0 SP2 and 3.0 SP2 setup such that it will never evaluate to true, and the REINSTALL=ALL property no longer gets automatically set.  As a result, you have to manually pass in the REINSTALL=ALL property in order to perform a full repair of the .NET Framework 2.0 SP2 and 3.0 SP2.

A while back, I wrote a blog post about how to perform silent repairs and uninstalls for the .NET Framework 2.0 SP1 and 3.0 SP1.  When the .NET Framework 3.5 SP1was released last fall, it included the .NET Framework 2.0 SP2 and 3.0 SP2 behind the scenes as prerequisites.  Those packages are both slipstream updates for the 2.0 SP1 and 3.0 SP1 versions, and because of that, the command lines used to repair or uninstall them have changed.

The following list provides example command lines that can be used to repair and uninstall the MSI-based .NET Framework 2.0 SP2 and 3.0 SP2 packages after they have been installed on the system:

.NET Framework 2.0 SP2 - silent repair

msiexec /fpecmsu {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REINSTALL=ALL REBOOT=ReallySuppress /l*v %temp%\netfx20sp2_repair_log.txt /qn

.NET Framework 2.0 SP2 - silent uninstall

msiexec /x {C09FB3CD-3D0C-3F2D-899A-6A1D67F2073F} REBOOT=ReallySuppress /l*v %temp%\netfx20sp2_uninstall_log.txt /qn

.NET Framework 3.0 SP2 - silent repair

msiexec /fpecmsu {A3051CD0-2F64-3813-A88D-B8DCCDE8F8C7} REINSTALL=ALL REBOOT=ReallySuppress /l*v %temp%\netfx30sp2_repair_log.txt /qn

.NET Framework 3.0 SP2 - silent uninstall

msiexec /x {A3051CD0-2F64-3813-A88D-B8DCCDE8F8C7} REBOOT=ReallySuppress /l*v %temp%\netfx30sp2_uninstall_log.txt /qn

Important notes:

• The .NET Framework 2.0 and 3.0 are installed as OS components on Windows Vista, Windows Server 2008 and Windows 7.  As a result, the MSI-based versions cannot be installed on these OS's, and the above command lines will not work on these OS's.  If you need to repair the .NET Framework 2.0 SP2 or 3.0 SP2 on these OS's, you will need to use instructions like the ones in this blog post.
• The .NET Framework 3.5 SP1 requires the .NET Framework 3.0 SP2 and 2.0 SP2 to be installed, so if you have the .NET Framework 3.5 SP1 installed, the above uninstall command lines will fail until you first uninstall the .NET Framework 3.5 SP1.
• Similarly, the .NET Framework 3.0 SP2 requires the .NET Framework 2.0 SP2 to be installed, so if you have the .NET Framework 3.0 SP2 installed, the above uninstall command line for the .NET Framework 2.0 SP2 will fail until you first uninstall the .NET Framework 3.0 SP2.
• The above examples use msiexec.exe to perform the repair and uninstall in fully silent mode.  If you choose to, you can use other supported Windows Installer command line parameters (described here and here) to perform unattended repairs and uninstalls or provide additional command line parameters to the setup processes.
• The above examples only demonstrate the command lines used for repair and uninstall.  For install scenarios, I recommend reviewing the content in the .NET Framework 3.5 deployment guides as well as the steps for creating administrative install points (here for 2.0 SP2 and herefor 3.0 SP2).
• The above msiexec command lines will return exit code 0 if the command completes successfully, 3010 if the command completes successfully and a reboot is required and some other numerical value if the command failed.  You can find a list of some standard Windows Installer return codes in this knowledge base article.

<update date="1/11/2012"> Added the REBOOT=ReallySuppress property to each command line so that the computer will not automatically reboot when running these command lines if the repair or uninstall process requires a reboot. </update>

Over the weekend, I posted an updated version of the .NET Framework setup verification tool that contains a few behavior changes that I wanted to describe here.  I have also updated the .NET Framework Setup Verification Tool User's Guide to reflect these changes, and you can find additional information and download links there as well.

• Added product version filtering logic to the verification tool
  
  Previously, the tool would allow you to choose to verify any version of the .NET Framework that it knows how to verify, even if that version was not actually installed on your system.
  
  Now, the tool will use the logic in the .NET Framework sample detection code to detect which version(s) and service pack level(s) of the .NET Framework are installed, and it will only show version(s) on the system in the UI.
  
  This logic will not apply if you run the tool in unattended or silent mode.  Those modes will function just like before and will allow you to attempt to verify any supported version of the .NET Framework, even if it is not detected as being installed on the system.
  
  
• Added a command line parameter to override the product filtering logic described above
  
  In case there is any need to run the .NET Framework setup verification tool in UI mode and choose a version of the .NET Framework that is not installed, you can run the tool with the new /a switch and cause it to skip filtering and instead allow you to select any version of the .NET Framework to verify, even if it is not detected as being installed on the system.
  
  Here is an example command line for the .NET Framework setup verification tool that will skip filtering:
  
  netfx_setupverifier.exe /q:a /c:"setupverifier.exe /a"
  
  
• Added an option to verify the .NET Framework 1.1 SP1
  
  Previously, the .NET Framework setup verification tool only offered the ability to verify the .NET Framework 1.1, but did not verify anything related to 1.1 SP1.
  
  Now, the tool includes the ability to verify the .NET Framework 1.1 and the .NET Framework 1.1 SP1.  As described above, only the version and service pack level that is detected as being installed on the system will be listed in the UI for the tool.
  
  
• Added better logging for registry values being verified
  
  Previously, the .NET Framework setup verification tool did not list the registry root of the keys and values it verifies in the log files that it creates (for example, it would only list Software\Microsoft\.NETFramework\Policy but not list HKEY_LOCAL_MACHINE).
  
  Now, the tool lists the full path to the registry keys and values that it verifies in the log files that it creates.
  

A while back, I posted some instructions that can be used to create an administrative install point for the .NET Framework 2.0 SP1.  Since then, the .NET Framework 2.0 SP2 has been released (it is required in order to install the .NET Framework 3.5 SP1).  Here are some updated steps that can be used to create an administrative install point for the .NET Framework 2.0 SP2 for each of the supported processor architectures.

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

1. Download the package named netfx20sp2_x86.exe from http://www.microsoft.com/downloads/details.aspx?FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f and save it to your local hard drive
2. Extract the contents of the setup package by running this command:
   netfx20sp2_x86.exe /x:c:\netfx20sp2\x86
3. Stage the base MSI by running this command:
   msiexec /a "c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\netfx20a_x86.msi" TARGETDIR="c:\netfx20sp2\x86\AIP"
4. Apply the patches to the staged base MSI by running this command:
   msiexec /a "c:\netfx20sp2\x86\AIP\netfx20a_x86.msi" PATCH="c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\ASPNET.msp;c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\CLR.msp;c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\CRT.msp;c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\NetFX_CA.msp;c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\NetFX_Core.msp;c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\NetFX_Other.msp;c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\PreXP.msp;c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\WinForms.msp;c:\netfx20sp2\x86\wcu\dotnetframework\dotnetfx20\DW.msp"

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

msiexec.exe /i c:\netfx20sp2\x86\AIP\netfx20a_x86.msi /l*v %temp%\netfx20sp2x86log.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 SP2 x64:

1. Download the package named netfx20sp2_x64.exe from http://www.microsoft.com/downloads/details.aspx?FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f and save it to your local hard drive
2. Extract the contents of the setup package by running this command:
   netfx20sp2_x64.exe /x:c:\netfx20sp2\x64
3. Stage the base MSI by running this command:
   msiexec /a "c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\netfx20a_x64.msi" TARGETDIR="c:\netfx20sp2\x64\AIP"
4. Apply the patches to the staged base MSI by running this command:
   msiexec /a "c:\netfx20sp2\x64\AIP\netfx20a_x64.msi" PATCH="c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\ASPNET_64.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\CLR_64.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\CRT_64.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\DW_64.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\NetFX_Core_64.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\NetFX_Other_64.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\WinForms_64.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\ASPNET.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\CLR.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\CRT.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\NetFX_CA.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\NetFX_Core.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\NetFX_Other.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\PreXP.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\WinForms.msp;c:\netfx20sp2\x64\wcu\dotnetframework\dotnetfx20\DW.msp"

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

msiexec.exe /i c:\netfx20sp2\x64\AIP\netfx20a_x64.msi /l*v %temp%\netfx20sp2x64log.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 SP2 ia64:

1. Download the package named netfx20sp2_ia64.exe from http://www.microsoft.com/downloads/details.aspx?FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f and save it to your local hard drive
2. Extract the contents of the package by running this command:
   netfx20sp2_ia64.exe /x:c:\netfx20sp2\ia64
3. Stage the base MSI by running this command:
   msiexec /a "c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\netfx20a_ia64.msi" TARGETDIR="c:\netfx20sp2\ia64\AIP"
4. Apply the patches to the staged base MSI by running this command:
   msiexec /a "c:\netfx20sp2\ia64\AIP\netfx20a_ia64.msi" PATCH="c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\ASPNET_i64.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\CLR_i64.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\CRT_i64.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\DW_i64.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\NetFX_Core_i64.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\NetFX_Other_i64.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\WinForms_i64.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\ASPNET.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\CLR.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\CRT.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\NetFX_CA.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\NetFX_Core.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\NetFX_Other.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\PreXP.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\WinForms.msp;c:\netfx20sp2\ia64\wcu\dotnetframework\dotnetfx20\DW.msp"

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

msiexec.exe /i c:\netfx20sp2\ia64\AIP\netfx20a_ia64.msi /l*v %temp%\netfx20sp2ia64log.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.

I just noticed this item on Charlie Owen's blog and wanted to post it here as well.  There is now a public download available for the Windows Media Center SDK for the Windows 7 beta.  Here are some useful links:

• SDK installer location - http://download.microsoft.com/download/7/5/0/7501F066-9B35-4F9E-8A63-0957687DE1E6/WindowsMediaCenterSDK6.msi
• Media Center development forum -http://discuss.mediacentersandbox.com/
• Summary of new Windows 7 Media Center features - http://blog.retrosight.com/WindowsMediaCenterInThePDCBuildOfWindows7.aspx
• Summary of new Windows 7 Media Center platform development features - http://blog.retrosight.com/WindowsMediaCenterPlatformInThePDCBuildOfWindows7.aspx

A while back, I posted some instructions that can be used to create an administrative install point for the .NET Framework 3.0 SP1.  Since then, the .NET Framework 3.0 SP2 has been released (it is required in order to install the .NET Framework 3.5 SP1).  Here are some updated steps that can be used to create an administrative install point for the .NET Framework 3.0 SP2 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 SP2 from an administrative install point.  These include the .NET Framework 2.0 SP2, MSXML 6.0, the RGB Rasterizer, the Windows Imaging Component (WIC) and the XML Paper Specification (XPS) shared components.  The .NET Framework 2.0 SP2 can be deployed using the steps in this previous blog post, and the other prerequisites can be deployed using the previously documented steps in the .NET Framework 3.0 deployment guide and the .NET Framework 3.5 deployment guide.

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

1. Download the .NET Framework 3.5 SP1 full package from http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/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:\netfx30sp2\x86\AIP"
4. Apply the patches to the staged base MSI by running this command:
   msiexec /a "c:\netfx30sp2\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 SP2 x86 located at c:\netfx30sp2\x86AIP.  You can then install the MSI directly using a command line like the following:

msiexec.exe /i c:\netfx30sp2\x86\AIP\netfx30a_x86.msi /l*v %temp%\netfx30sp2x86log.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 SP2 x64:

1. Download the .NET Framework 3.5 SP1 full package from http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/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:\netfx30sp2\x64\AIP"
4. Apply the patches to the staged base MSI by running this command:
   msiexec /a "c:\netfx30sp2\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 SP2 x64 located at c:\netfx30sp2\x64\AIP.  You can then install the MSI directly using a command line like the following:

msiexec.exe /i c:\netfx30sp2\x64\AIP\netfx30a_x64.msi /l*v %temp%\netfx30sp2x64log.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.

I have heard from a few people who have run into error code 25015 with a data error (cyclic redundancy check) message while trying to install the .NET Framework 2.0, 2.0 SP1 or 2.0 SP2.  This error can also occur during .NET Framework 3.0, 3.5 or 3.5 SP1 setup because all of these versions of the .NET Framework will attempt to install the .NET Framework 2.0 behind the scenes.

How to diagnose this error

When this error occurs, the following information appears in a dialog box and/or in the verbose MSI log file (named %temp%\dd_netfx20MSI*.txt for the original release of the .NET Framework 2.0 and %temp%\dd_net_framework20*.txt for the .NET Framework 2.0 SP1 or SP2):

Error 25015.Failed to install assembly
'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Visual Basic.dll' because of system error: Data error (cyclic redundancy check)

MSI (s) (A1!B0) [12:34:56:111]: Product: Microsoft .NET Framework 2.0 Service Pack 1 -- Error 25015.Failed to install assembly 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Visual Basic.dll' because of system error: Data error (cyclic redundancy check).

Note that the exact file that is listed in these error messages can vary across computers, but typically they will list the same file each time if you re-run setup on the same computer.

How to work around this error

In many of the cases I've seen where this exact data error (cyclic redundancy check) message appears, the root cause ended up being some corrupt sectors on the hard drive.  If that is the cause, then it can help to run the Chkdsk tool that ships with Windows to scan the hard drive and repair any corrupt sectors that it finds.

To run Chkdsk and repair corrupt sectors, you can use the following steps:

1. (on Windows Vista and higher) Click on the Start menu, choose All Programs, then Accessories, then right-click on the item named Command Prompt and choose Run as administrator
2. (on versions of Windows before Vista) Click on the Start menu, choose Run, type cmd and click OK
3. Run this command:  chkdsk c: /R
   
   Note: This command will scan the C drive.  You should substitute the C drive with whatever drive your Windows directory is on if it is not on the C drive.  The drive letter used in this command should match the drive letter listed in the error message.
   
   
4. Wait for the command to finish - it can take a while, especially if the drive letter it is scanning has a lot of hard drive space.
5. After the command finishes, try again to install the .NET Framework

What to do if the workaround does not help

I want to mention one caveat here that I typically include in all of my .NET Framework troubleshooting blog posts - there are many possible causes for .NET Framework setup failures, and this blog post only describes one of them.  The above workaround will likely not help solve all possible installation issues.  If this workaround does not help in your scenario, then I suggest looking at 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.

A while back, I posted a set of steps that you can use to create an MSI with WiX and combine it with a Visual Studio setup.exe bootstrapper to create an installer that can chain prerequisites and then install the MSI.  Since then, I've gotten a couple of questions about odd behaviors that customers have observed in the Visual Studio bootstrapper, and I've learned about a couple of issues about that bootstrapper technology and how to work around them that I wanted to describe here.

Issue 1 - problem creating a self-extracting package with the Visual Studio 2008 bootstrapper

If you use Visual Studio 2008 to create a VS bootstrapper package, you will notice that the setup.exe process exits as soon as it launches the install process for your MSI.  That typically causes problems if the setup.exe is embedded in a self-extracting package.  Because setup.exe exits before the overall installation process is complete, the self-extracting package will try to clean up and exit, and that can end up deleting files that are needed by the MSI that is still in the process of installing.

This behavior is new in bootstrapper packages created with Visual Studio 2008, and the change is designed to allow the bootstrapper to work better with UAC on Windows Vista.  There are a couple of options available to you to work around this issue if needed:

• Write a small stub program that will call the VS bootstrapper setup.exe package, and that knows how to monitor the status of the setup.exe process and the msiexec.exe process that will be used to install your MSI.  That stub can wait for both processes, and then exits only after both are done.  This will allow the self-extracting package to clean up only when all installation actions are done.
• Use Visual Studio 2005 to create your setup.exe bootstrapper instead of Visual Studio 2008.

Issue 2 - problem displaying download progress for the MSI via the Visual Studio 2008 bootstrapper

If you use Visual Studio 2008 to create a VS bootstrapper package, and you configure the bootstrapper to download your MSI from the Internet (by using the HomeSite value for the ComponentsLocation attribute in the GenerateBootstrapper task), you may not see any progress UI while the MSI is being downloaded.  This is a bug in the VS 2008 bootstrapper that is fixed in VS 2008 SP1.  To fix this, you can install VS 2008 SP1 and rebuild your setup.exe bootstrapper.

When you rebuild setup.exe, make sure that you use the version of msbuild.exe that is in the .NET Framework 3.5 directory (%windir%\Microsoft.NET\Framework\v3.5\msbuild.exe) and not the copy of msbuild.exe in the .NET Framework 2.0 directory (%windir%\Microsoft.NET\Framework\v2.0.50727\msbuild.exe) or else you will not see the download progress for your MSI, even if you have VS 2008 SP1 installed.

Last week, I posted an item about the release of the XNA Game Studio 3.0 Japanese documentation installer.  This package allows you to install a local collection of Japanese help topics for XNA Game Studio 3.0.  This documentation is stored on the local file system and can be accessed in the Visual Studio help viewer even if the computer does not have an active Internet connection.

Today, the XNA Game Studio 3.0 Japanese help documentation was also published to the online MSDN library at http://msdn.microsoft.com/ja-jp/library/bb200104.aspx.  This enables users to search online for Japanese help topics for XNA Game Studio 3.0.  In addition, you can configure Visual Studio 2008 and Visual C# 2008 Express Edition to automatically load the online Japanese help documentation first if it is able to access the Internet.  To change the Visual Studio online help language preferences, you can do the following:

1. Open Visual Studio 2008 or Visual C# 2008 Express Edition, click on the Tools menu and choose Options...
2. If you are running Visual C# 2008 Express Edition, click the check box in the bottom left corner of the Options dialog to show all settings
3. Under the Environment item, click on the Help item
4. Change the Online topic language to Japanese if it is not already set that way
5. Click on the Online item
6. In the radio button group labeled When loading Help content, choose one of the options that will allow Visual Studio to attempt to load online content

These steps will allow you to view Japanese help documentation for XNA Game Studio 3.0 even if you do not download and install the Japanese documentation package, but it does require your computer to have Internet access at the time you try to view help topics.  You can also click the check box on the Help item in the Visual Studio options page to cause it to display the English versions of the help topics as well if you choose to.

Last Friday (February 13, 2009), an update for XNA Game Studio Connect was released via Xbox LIVE Marketplace.  This update is described in more detail in this post on Michael Klucher's blog.  To quickly summarize, some changes were made to allow developers to debug and peer review scenarios that previously were only available after a game had been published to Xbox LIVE Community Games (specifically, the Community Games splash screen and the trial mode expiration screen).

If you are using XNA Game Studio 3.0 for Xbox 360 development and already have XNA Game Studio Connect, you don't need to do anything special to get this update.  It will be automatically offered to you the next time you launch XNA Game Studio Connect.

As always, if you have any questions or comments about XNA Game Studio development, please check out the following resources:

• XNA community forums
• Connect bug reporting and feature suggestion site