We recently released Update Rollup 1 for eHome Infrared Receivers for Windows XP Media Center Edition 2005.  There are some fixes in this package that may cause your Media Center remote control to stop working.  Specifically, we previously allowed channels 1-8 to broadcast IR signals on, and with this package installed the remote is limited to channels 1-4.  If your remote is broadcasting on channels 5-8, here is what you can do to change to a channel in the 1-4 range to allow it to start working again:

• Hold down the “DVD Menu” button and the “1” key at the same time for 5 seconds (or the "2", "3" or "4" key if you want to have the remote broadcast on one of the other supported channels instead
• After 5 seconds, the LED on the IR receiver should blink twice, and your remote should work correctly again.

Question:

I have built an installer using the Visual Studio 2005 setup project wizard.  It installs correctly on Windows XP but fails on Windows Vista.  I investigated and found that the failure on Windows Vista is caused by a custom action that fails with an access denied error.  However, I am running the setup with elevated privileges in Windows Vista.  How can I fix my setup so it will work correctly on Windows Vista?

Answer:

As Robert Flaming described in this blog post, it is necessary to set the NoImpersonate flag for custom actions that modify the system in Windows Vista.  This was an uninforced architectural intent that is now enforced in Windows Vista.

Unfortunately, there is not a way to directly set this flag for a custom action in the UI for the setup project in the Visual Studio IDE.  In Visual Studio 2005, you can use a post-build step that modifies the MSI to set this bit using a strategy previously described in this blog post.

You can use the following steps to set the NoImpersonate bit in a Visual Studio 2005 setup project:

1. Download the sample script and extract the contents to the directory that contains the Visual Studio project you are working on
2. Open the project in Visual Studio 2005
3. Press F4 to display the Properties window
4. Click on the name of your setup/deployment project in the Solution Explorer
5. Click on the PostBuildEvent item in the Properties window to cause a button labeled "..." to appear
6. Click on the "..." button to display the Post-build Event Command Line dialog
7. Add the following command line in the Post-build event command line text box:
   cscript.exe "$(ProjectDir)CustomAction_NoImpersonate.js" "$(BuiltOuputPath)"
8. Build your project in Visual Studio 2005

<update date="1/22/2007"> Updated command line in step 7.  The variable I had specified previously was incorrect.  It actually needs to be spelled wrong using "ouput" instead of "output" in the $(BuiltOuputPath) variable </update>

<update date="3/18/2009"> Fixed broken link to the sample script. </update>

Heath Stewart posted an item on his blog this past week that I wanted to raise awareness about.  In the post, located at http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx, Heath described some potential issues and workarounds for script-based custom action failures in MSI-based setups.

These error codes appear in an MSI log file when a script-based custom action fails to run correctly, and the error messages look like the following:

• 2738, Could not access VBScript run time for custom action [2].
• 2739, Could not access JScript run time for custom action [2].

A common resolution for this type of error is to re-register the file %windir%\system32\vbscript.dll and/or %windir%\system32\jscript.dll.  However, on Windows Vista this can present problems because if you attempt to re-register these DLLs from a normal user cmd prompt, the registration will be written to HKEY_CURRENT_USER instead of HKEY_CURRENT_MACHINE.

A key point Heath makes in his blog post that I was not aware of before reading it is that Windows Installer will not load and use scripting engines if they are registered in HKEY_CURRENT_USER (for security reasons that he described in more detail in his post).  Therefore, if you have registered the DLLs on Windows Vista from a normal user cmd prompt, that will not help fix this type of error.

If you have these scripting engines registered under HKEY_CURRENT_USER, you need to make sure that you remove that registration and re-register them under HKEY_LOCAL_MACHINE.  You can use the following steps to unregister them from HKEY_CURRENT_USER:

1. Click on the Start menu, choose Run, type cmd and click OK
2. To unregister the VBScript engine, run this command:  reg delete "HKCU\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}" /f
3. To unregister the VBScript engine on a 64-bit OS, run this command:  reg delete "HKCU\SOFTWARE\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11CF-A4B0-00AA004A55E8}" /f
4. To unregister the JScript engine, run this command: reg delete "HKCU\SOFTWARE\Classes\CLSID\{F414C260-6AC0-11CF-B6D1-00AA00BBBB58}" /f
5. To unregister the JScript engine on a 64-bit OS, run this command: reg delete "HKCU\SOFTWARE\Classes\Wow6432Node\CLSID\{F414C260-6AC0-11CF-B6D1-00AA00BBBB58}" /f

One last note - if you are a setup developer reading this post, I encourage you to read this post by Rob Mensching where he explains reasons why using script-based custom actions in an MSI can lead to bad results and should be avoided if at all possible.

<update date="7/29/2009"> Added steps to unregister the VBScript and JScript engines on 64-bit OS's. </update>

Note - the issue described in this blog post was originally presented as an issue on Windows XP SP2.  However, it can also affect .NET Framework 1.0 and 1.1 installation on any OS released after the .NET Framework 1.0 and 1.1 shipped - specifically, I have seen reports of this issue on Windows Vista.  The steps listed here are applicable to this type of install failure on other newer OS's like Windows Vista and not just Windows XP SP2. 

As I was researching the bug in .NET Framework 1.0 and 1.1 that is related to regional language settings on Windows XP SP2 (see this blog post for full details), I discovered an additional issue introduced in Windows XP SP2 that can cause .NET Framework 1.0 or 1.1 setup to fail.  Just like the other bugs, this one causes .NET Framework setup to report an error while registering System.EnterpriseServices.dll.  In the case of .NET Framework service pack setup, it will cause an error to occur while extracting the service pack to a temporary location before even starting setup.

Windows XP SP2 introduced a new security feature known as Data Execution Prevention (or DEP for short).  There is a good article introducing DEP here.  If a computer running XP SP2 has hardware that supports DEP and DEP is enabled in boot.ini, installation of the .NET Framework will fail while trying to register System.EnterpriseServices.dll (which happens to be the first time that managed code gets run during setup and therefore is the first time the bug is hit).  Also, installation of .NET Framework service packs will fail while trying to extract the service pack setup to a temporary location because the .NET Framework service pack wrapper is written in managed code.

The DEP feature was introduced after the .NET Framework 1.0 and 1.1 shipped and unfortunately the .NET Framework is not compatible with DEP without applying a service pack.  Like the language settings bug, this DEP compatibility bug has been fixed in the .NET Framework 1.0 SP3 and 1.1 SP1.  However, this bug causes the initial installation of the .NET Framework to fail and rollback, and you cannot install the service pack without first getting the product installed (unless you use a method like I describe here, which will work but is not "officially" supported).

If you are running into this bug on your Windows Vista, Windows Server 2008 or Windows 7 computer, you can use steps like the ones in this blog post to work around this bug in the .NET Framework 1.0 and 1.1 and get it installed. 

If you are running into this bug on your Windows XP SP2 computer, you can use the following steps to work around this bug in the .NET Framework 1.0 and 1.1 and get it installed:

1. From the Start menu, type sysdm.cpl in the Run box or go to Control Panel and choose the System item
2. Click the Advanced tab
3. Click the Settings button in the Startup and Recovery section of this tab
4. In the Default operating system dropdown, select each option that starts with "Microsoft Windows XP Professional" and change /NoExecute=Optin to /NoExecute=AlwaysOff.  This will update the settings in boot.ini on the computer
5. Click OK
6. Restart
7. Install the .NET Framework 1.0 or 1.1
8. Install .NET Framework 1.0 SP3 or 1.1 SP1
9. Return to the System control panel, select each option that starts with "Microsoft Windows XP Professional" and change /NoExecute=AlwaysOff back to /NoExecute=Optin

For reference, here is what the Startup and Recovery item in the Advanced tab of the System control panel looks like (this is the screen you will see in step 4 of the instructions above):

<update date="4/17/2008"> Added a note indicating that the issue in this post can affect the .NET Framework 1.0 and 1.1 setup on Windows Vista and not just Windows XP SP2 </update>

<update date="6/23/2009"> Fixed broken image link, and added a link to a separate blog post that provides steps for turning DEP on and off on Windows Vista and higher. </update>

A while ago, I published a .NET Framework setup verification tool that can be run to provide a sanity check of the install state of the .NET Framework 1.0, 1.1 and 2.0 on a system.  However, there are some limitations in that tool:

• It does not support validating the .NET Framework 2.0 on Windows Vista
• It does not support the .NET Framework 2.0 SP1, the .NET Framework 3.0, the .NET Framework 3.0 SP1 or the .NET Framework 3.5
• It only checks file version information and does not check registry values created by setup
• It depends on the setup technology used to install the product in the first place (Windows Installer or OS install technologies) and requires you to select an OS-specific version of the product in the UI in order to get accurate verification results
• It reports misleading warnings if hotfixes for the .NET Framework are installed on the system

As a result, I decided to create a new verification tool, and I have an initial version that I think is ready for more people to use.  I wanted to post some information about the tool so that folks can try it out to verify the installation state of the various versions of the .NET Framework on their systems.

Where to download the new verification tool

I have a draft version of a new verification tool that can be used to verify all versions of the .NET Framework (1.0, 1.1, 2.0, 2.0 SP1, 3.0, 3.0 SP1 and 3.5) on any supported OS and processor architecture.  You can find information about the tool and download it from this location:

http://blogs.msdn.com/astebner/pages/8999004.aspx

The UI for the tool is straightforward - it contains a drop-down list box that lets you choose the version of the .NET Framework that you would like to verify and a Verify Now button to initiate the verification process for the chosen product.  After verification completes, it will display results for the chosen product and allow you to select additional products to verify.

I have been testing this new version on several systems that I have access to, but there are likely to still be issues where the tool falsely reports errors or misses some error cases.  Please let me know if you see any issues while using this tool by posting comments on this blog post or by contacting me directly.  If possible, please include information about your scenario and copies of the log files that I describe below so I can continue to make this tool better in the future.

How to run the tool in silent mode

This verification tool supports running in silent mode if you would like to automate the verification process.  To run in silent mode, you need to download the verification tool .zip file, extract the file netfx_setupverifier.exe from the .zip file, and then run it using syntax like the following:

netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p <name of product to verify>"

The value that you pass with the /p switch to replace <name of product to verify> in this example must exactly match one of the products listed in the file setupverifier.ini that is included in the self-extracting package for the verification tool.

Currently, the verification tool includes the following product names that can be passed in using the /p switch:

• .NET Framework 1.0
• .NET Framework 1.1
• .NET Framework 2.0
• .NET Framework 2.0 SP1
• .NET Framework 2.0 SP2
• .NET Framework 3.0
• .NET Framework 3.0 SP1
• .NET Framework 3.0 SP2
• .NET Framework 3.5
• .NET Framework 3.5 SP1

For example, if you would like to run the tool in silent mode and verify the install state of the .NET Framework 2.0, you would use a command line like the following:

netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p .NET Framework 2.0"

The verification tool returns the following exit codes:

• 0 - cleanup completed successfully for the specified product
• 1 - the required file setupverifier.ini was not found in the same path as setupverifier.exe
• 2 - a product name was passed in that cannot be verified because it does not support installing on the OS that the tool is running on
• 3 - a product name was passed in that does not exist in setupverifier.ini
• 100 - verification failed for the specified product
• 1602 - verification was canceled

Logging

This verification tool creates 2 log files by default that can be used to determine what actions the tool is taking and what errors it encounters while verifying a product.  The 2 log files are listed below, and they are created in the %temp% directory by default.  Note that you can find the %temp% directory by clicking on the Windows start menu, choosing Run, typing %temp% and clicking OK to open the directory in Windows Explorer.

• %temp%\setupverifier_main_*.txt - this log contains information about all actions taken during a verification tool session; it will include information about each resource that the tool attempts to verify for a chosen product and whether or not that resource was found on the system; this log tends to be fairly long, so errors will be logged with the prefix ****ERROR**** to make it easy to search and find them
• %temp%\setupverifier_errors_*.txt - this log only contains information about any errors found during verification of a chosen product

A new pair of log files will be created each time the verification tool is launched.  The date and time the tool is launched will be appended to the end of the log file names by default in place of the * in the names listed above.  If you want to control the exact names used for the log files, you can use the following command line parameters:

• /l <filename> - specifies a name to replace the default value of setupverifier_main_*.txt for the main activity log for the verification tool
• /e <filename> - specifies a name to replace the default value of setupverifier_errors_*.txt for the error log for the verification tool

For example, the following command line will allow you to specify non-default names for both log files:

netfx_setupverifier.exe /q:a /c:"setupverifier.exe /l %temp%\my_main_log.txt /e %temp%\my_error_log.txt"

<update date="9/2/2009"> Fixed broken link to the verification tool. </update>

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.

With the release of VS 2005 and the .NET Framework 2.0, we began to use a new Windows Installer external UI handler to manage installation of several of the setups that are part of the VS 2005 family, including the .NET Framework 2.0 redistributable and SDK, J# redistributable, VS Tools for Office redistributable, language packs .NET, J# and VS Tools for Office, etc.

This new external UI handler is named install.exe, and you will find an INI file named install.ini included with each product that uses install.exe.  Install.ini expresses many configuration options for the setup in question.  I have described many of the settings used for the .NET Framework 2.0 redistributable in this blog post.

In addition to the INI file, install.exe can be configured using several command line switches.  The following list provides information about all of the command line switches that are supported by the install.exe external UI handler in the VS 2005 and .NET Framework 2.0 family of products:

• /a - Launches setup in administrative mode.  This mode is used to create a Windows Installer administrative install point that can then be used to install or deploy the product from.  Administrative mode presents UI that allows you to choose the location to stage the files to
• /l <log file> - Causes setup to create a verbose log in a non-default path.  Setting this value will override the value of the VerboseLog entry in the install.ini file.  If the /l switch is passed, the log file name is required.  If it is provided, it will override the LogFilePrefix entry in install.ini.  If you choose to pass a log file name and there is a space in the path, you will need to enclose the name in quotes.  Leaving this parameter off will allow setup to create a verbose log file in the %temp% directory that has a name beginning with the LogFilePrefix entry in install.ini and ending with a randomly generated character sequence.
• /lang #### - Specifies the 4-digit language code for the language in which to display the setup UI.  This setting overrides the OS language check and the language specified in the install.ini file.  Setup looks for a file named install.res.####.dll in the same path as install.exe and attempts to load strings from that DLL.  If the DLL with the numerical value passed in via this command line parameter does not exist, install.exe falls back to English strings (located in install.res.1033.dll).  If install.res.1033.dll also does not exist, setup will display an error dialog and exit
• /msipassthru MSI_PROP_BEGIN"<properties with quotes here>"MSI_PROP_END - Specifies additional property/value pairs that will be passed to the Windows Installer MsiInstallProduct API (or msiexec.exe). This switch also requires that a token be used to prefix/postfix the actual command line arguments.  For example: /msipassthru MSI_PROP_BEGIN"PROPERTY1=Value1 PROPERTY2=Value2"MSI_PROP_END
• /msipassthru MSI_ARGS_FILENAME_BEGIN<path to file with properties>MSI_ARGS_FILENAME_END - Specifies the full path to a file that contains additional property/value pairs that will be passed to the Windows Installer MsiInstallProduct API (or msiexec.exe)
• /q - Specifies quiet install mode. Suppresses the display of all setup UI during installation
• /qb - Specifies basic UI mode for installation.  This will cause install.exe to only show a small Windows Installer progress dialog with no other user interaction required.  This is the equivalent of the msiexec.exe /qb command line switch
• /qb! - Extends the /qb switch by hiding the cancel button on the progress dialog during installation.  This is the equivalent of the msiexec.exe /qb! command line switch
• /qu - Specifies quiet uninstall mode.  Suppresses the display of all setup UI during uninstallation
• /skip_all_checks - Causes install.exe to skip all prerequisites checks that are specified in install.ini.  This may result in setup failing elsewhere because some of the checks are also specified in the MSI itself.  However, this can be useful as a troubleshooting tool if you know the state of the machine(s) that you are installing on very well
• /watsonsilent - Causes all Watson reports generated by setup in the case of failure to be silently sent to Microsoft instead of displaying a dialog.  This command line switch is only applicable if one of the /q flags is also used
• /watsonui - Causes all Watson reports generated by setup in the case of failure to display UI informing the user of the issue
• /? - Displays a help dialog with information about supported command line parameters.  As I was writing this article I noticed that many of the switches that are supported by install.exe are not actually listed in this dialog.  I'll be reporting a bug to the setup team so that hopefully this will be cleaned up in a future release to present more useful information to the user

<update date="12/7/2005"> Added a note to the /l log file switch indicating that you need to put quotes around the file name if there are spaces in the name </update>

Question:

I have seen your blog posts that describe how to silently repair and uninstall the following versions of the .NET Framework:

• .NET Framework 1.0
• .NET Framework 1.1
• .NET Framework 2.0
• .NET Framework 2.0 SP1 and 3.0 SP1
• .NET Framework 2.0 SP2 and 3.0 SP2
• .NET Framework 3.5

How can I perform a silent repair and uninstall for the .NET Framework 3.5 SP1?

Answer:

The following list provides example command lines that can be used to repair and uninstall the MSI-based .NET Framework 3.5 SP1 package after it has been installed on the system.  The silent option will perform the repair/uninstall with no UI displayed to the user.  The unattended option will perform the repair/uninstall with only a progress dialog, but with no user interaction required.

.NET Framework 3.5 SP1 - silent repair

"%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /q /norestart

.NET Framework 3.5 SP1 - unattended repair

"%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /qb /norestart

.NET Framework 3.5 SP1 - silent uninstall

"%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /q /uninstall /norestart

.NET Framework 3.5 SP1 - unattended uninstall

"%windir%\Microsoft.NET\Framework\v3.5\Microsoft .NET Framework 3.5 SP1\setup.exe" /qb /uninstall /norestart

Important notes about repair scenarios:

• The .NET Framework 3.5.1 (an updated version of the .NET Framework 3.5 SP1) is installed as an OS component on Windows 7.  As a result, the MSI-based versions of 3.5 or 3.5 SP1 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 3.5.1 on Windows 7, you will need to use instructions like the ones in this blog post.
• On Windows XP and Windows Server 2003, the .NET Framework 3.5 SP1 repair process will chain the repair processes for the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2, so there is no need to use separate steps to repair those products if you are going to repair the .NET Framework 3.5 SP1 on these OS's.
• On Windows Vista and Windows Server 2008, the .NET Framework 2.0 and 3.0 are OS components, and the repair of the .NET Framework 3.5 or 3.5 SP1 will not repair these OS components.  If you need to repair the .NET Framework 2.0 and/or 3.0 on Windows Vista or Windows Server 2008, you will need to use instructions like the ones in this blog post.

Important note about uninstall scenarios:

• The .NET Framework 3.5 SP1 uninstall process will only uninstall the .NET Framework 3.5 SP1 MSI.  It will not uninstall the .NET Framework 2.0 SP2 or the .NET Framework 3.0 SP2 products because there may be other applications on the system that rely on those versions of the .NET Framework.  If you want to uninstall the .NET Framework 2.0 SP2 and 3.0 SP2, you must uninstall in the following order:  .NET Framework 3.5 SP1, then .NET Framework 3.0 SP2 then .NET Framework 2.0 SP2.

Other important notes:

• Log files will be created for the .NET Framework 3.5 SP1 repair and uninstall just like for the initial install.  You can find a list of .NET Framework 3.5 and 3.5 SP1 log files in this blog post.
• When calling .NET Framework 3.5 SP1 setup in silent or unattended mode, you should check the return code from the setup.exe process in order to determine success or failure.  Return code 0 means that the setup was successful, return code 3010 means that the setup was successful but a reboot is required to complete the setup and any other return code means that there was an error.  If you receive a 3010 return code, the reboot is required before all .NET Framework functionality will be expected to function correctly on the user's system, so it cannot be deferred forever.
• 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.

There is a known issue in Update Rollup 2 for Media Center 2005 that causes 5.1 analog surround sound to revert to 2 channel mode.  The underlying issue is that a registry setting is being overwritten by Media Center.  You can use the following steps to add the registry value needed to fix this issue:

1. Close Media Center
2. Click on the Start menu, choose Run and type cmd
3. Run the command reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Media Center\Service\Video" /v AudioOutputFormat /d {696E1D31-548F-4036-825F-7026C60011BD} /f

Note that if you re-run the Speaker Setup portion of Media Center Setup, this registry value will be reset again and you will need to re-run the above command to fix the underlying issue once more.

This issue was previously described on this NVidia support page, but I wanted to list it here as well in case anyone reading my blog runs into it as well.

I got a question from a customer who found this blog post describing how to chain silent installation of VS .NET 2003 prerequisites, VS .NET 2003 and MSDN.  They wanted to know what the equivalent set of steps would be for chaining silent installation of VS 2005.  There have been some modifications to how setup works behind the scenes in VS 2005, most notably the elimination of the separate step that used to be required to install prerequisite components for VS, so happily I can say these steps are much simpler than in the past.  Here are the steps for VS 2005 (using the same format as my previous post).

To start with you should stage Visual Studio bits to a network share so that you can use this as your installation source later on.  You can accomplish that with the following steps (also described in the VS readme located in the file adminreadme.htm in the Setup subdirectory on VS Disk 1):

1. Create a folder on your server, such as \\server\vs2005
2. Create subfolders named \\server\vs2005\vs and \\server\vs2005\msdn
3. Copy the contents of all CDs labeled Visual Studio 2005 to \\server\vs2005\vs.  If prompted, choose yes to overwrite existing files.
4. Copy the contents from all the CDs labeled MSDN Library for Visual Studio 2005 to \\server\vs2005\msdn.  If prompted, choose yes to overwrite existing files.
   NOTE: You can substitute a different MSDN Quarterly Library for the version of MSDN that shipped with Visual Studio 2005 if you choose

Now that you have a network image, you can create the unattended INI file to install VS 2005 and MSDN using the following steps:

1. Locate a test computer that has the same operating system that you want to deploy Visual Studio to in your network, and make sure that it does not already have Visual Studio 2005 installed
2. Install .NET Framework 2.0 on your test computer (because this is required for creating an unattend file for Visual Studio in the next step)
3. Run \\server\vs2005\vs\setup\setup.exe /createunattend \\server\vs2005\datafiles\vs.ini /vsupdate=\\server\vs2005\MSDN\setup.exe /vsupdateargs="qn"
4. Open \\server\vs2005\datafiles\vs.ini, go to the [PostSetupLaunchList] section and change """qn""" to /qn
5. Go to a clean computer without Visual Studio 2005 installed and run \\server\vs2005\vs\setup\setup.exe /unattendfile \\server\vs2005\datafiles\vs.ini to test the unattended installation process

There are a couple of gotchas that I have seen that you should keep an eye out for when following these instructions:

• Make sure to note the extra \setup\ directory for the Visual Studio setup.exe in the steps above.  Unattended installation will not work correctly if you run the setup.exe in the root of the \\server\vs2005\vs folder; you must use \\server\vs2005\vs\setup\setup.exe.
• Make sure that you have write permission for the location that you create your data file at in step 3 (in this example I used \\server\vs2005\datafiles).  You will get an error if you try to create the data files on a share that you do not have write permissions for.
• Make sure that you create the INI file on a computer that does NOT already have Visual Studio 2005 installed.  If you have VS installed, you will end up creating an INI file for a maintenance mode update instead of an initial install of VS.
• The INI file for VS is unique to each version of VS (such as Pro, Standard, Team System), and also unique to the OS that you want to install on (Windows 2000, Windows XP, etc).  Make sure that you create INI files on computers that match what you will eventually be deploying to.

There is an advanced trick that you can use when creating this unattend script as well:

• If you want to perform a full install of MSDN to the local hard drive instead of a default installation, you can read the steps at this blog post to learn how to update your vs.ini file to call MSDN setup with the correct parameters to accomplish this.

In the VS 2003 instructions there was an additional advanced trick regarding waiting for the setup process to exit and checking the return code.  The workaround I listed in my previous post is not necessary in VS 2005 because setup now has specific logic to not copy itself to the %tmep% folder and start a new process if it detects it is being run in administrative installation mode.

Question:

I recently installed the .NET Framework 3.5 SP1 on my system.  Afterwards, I looked in Add/Remove Programs, and it shows that I have all of the following versions of the .NET Framework installed on my system:

• Microsoft .NET Framework 1.0
• Microsoft .NET Framework 1.1
• Microsoft .NET Framework 2.0 SP2
• Microsoft .NET Framework 3.0 SP2
• Microsoft .NET Framework 3.5 SP1

Do I need any of these older versions of the .NET Framework now that I’ve installed the .NET Framework 3.5 SP1, or can I safely uninstall them?

Answer:

When you install the .NET Framework 3.5 SP1, it will also install the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2 behind the scenes.  You cannot use the .NET Framework 3.5 SP1 unless you also have the .NET Framework 2.0 SP2 and 3.0 SP2 installed.  Therefore, you will not be allowed to uninstall the .NET Framework 2.0 SP2 or 3.0 SP2 if you have the .NET Framework 3.5 SP1 installed.  If you try to uninstall those versions of the .NET Framework, their uninstall processes will block and tell you that they are needed by another application on your system.

The .NET Framework 1.0 and .NET Framework 1.1 can be installed side-by-side with the .NET Framework 2.0, 3.0 and 3.5.  Most applications that were created for the .NET Framework 1.0 or 1.1 will automatically use the .NET Framework 2.0 instead if it is installed on the system.  In most cases, that means you do not need to keep the .NET Framework 1.0 or 1.1 installed on your system if you already have the .NET Framework 2.0 installed.

However, there are some applications that are configured to require a specific version of the .NET Framework, even if later versions of the .NET Framework are installed.  If you have any applications like that on your system and try to run them without installing the .NET Framework 1.0 or 1.1, you will get an error message that looks like the following:

---------------------------
MyApplication.exe - .NET Framework Initialization Error
---------------------------
To run this application, you first must install one of the following versions of the .NET Framework:
  v1.1.4322
Contact your application publisher for instructions about obtaining the appropriate version of the .NET Framework.
---------------------------
OK  
---------------------------

In the above error message, the version number will be v1.0.3705 if you need to install the .NET Framework 1.0, and it will be v1.1.4322 if you need to install the .NET Framework 1.1.

If you end up seeing any error messages like this, you can re-install the .NET Framework 1.0 or 1.1 in order to resolve the errors.  If you don't end up seeing any error messages like this, then you don't need to worry about re-installing the .NET Framework 1.0 or 1.1.

Important note: The issue described in this blog post only affects pre-RC1 builds of Windows Vista.  If you are running Windows Vista RTM and have problems installing the .NET Framework, do not try this workaround because it does not apply to the RTM build and will not help.  Please see http://blogs.msdn.com/astebner/articles/454956.aspx instead of this blog post if you have problems installing the .NET Framework 1.1 on Windows Vista RTM.....

The .NET Framework setup team recently discovered a compatibility bug that will prevent the .NET Framework 1.1 from installing on the most recent build of Windows Vista that was released to the Windows Vista beta program members (build 5456). 

The underlying problem is that one of the type libraries registered by .NET Framework 1.1 setup is attempting to write to a registry sub-key that is incorrectly marked read-only in this build of Windows Vista.  In order to workaround this issue, you will need to change owners and modify permissions on a registry sub-key on your system.

You can perform the following steps before installing the .NET Framework 1.1 to workaround this issue on Windows Vista build 5456:

1. Click on the Start menu, choose All Programs, then Accessories
2. Right-click on Command Prompt and choose Run as administrator
3. From the command prompt, type regedit
4. Navigate to HKEY_LOCAL_MACHINE and then Software\Classes\Interface\{65074F7F-63C0-304E-AF0A-D51741CB4A8D}\TypeLib
5. Right-click on the TypeLib sub-key and choose Permissions
6. Click the Advanced button
7. Click on the Owner tab
8. Select the Administrators group in the Change owner to: list and click Apply to change the owner of this sub-key
9. Click on the Permissions tab, highlight SYSTEM and click the Edit button
10. Check the Full Control check box and click OK to change the permissions on this sub-key for the SYSTEM account
11. Close regedit

After performing the above steps, you should be able to re-run .NET Framework 1.1 setup and install successfully.

<update date="4/4/2007"> Added note at the top of this blog post to try to let users know that this workaround will not help in the final RTM release of Windows Vista.  </update>

Steven Bone posted the first of a series of articles about how Windows Installer custom actions work and how to create and debug them.  You can click on the link to read Part 1 - Custom Action Types and Sequences.

This article describes how to configure the columns of the custom action table in an MSI, when to use immediate and deferred custom action types, how to handle rollback, and when to use the various custom action flags, options and conditions.

When using Windows Installer to create a setup, you can author most necessary actions using the standard MSI tables.  However, there are some types of actions that are not supported using native MSI tables (such as the list I posted a while back).  Because of this, using custom actions in your MSI will sometimes be necessary.  Building a setup package is an integral part of the software development process, and the same level of care should be put into planning and designing the setup and deployment for your software.

Therefore, I strongly encourage you to read through this article (and the follow-up articles he will be posting in the future about writing custom action code) if you do any kind of setup development or testing work.

I also wanted to point out that there is a set of commonly needed custom actions that are published with the WiX toolset, and they can be easily incorporated into a setup package without needing to write any additional code.  If you are writing an MSI-based setup I encourage you to take a look at WiX as well.

I wanted to take a minute to spotlight one of the big new embedded enabling features that is new to Windows XP Embedded SP2.  It is called hibernate once, resume many.  We have taken to abbreviating this to HORM internally, so if you see this new acronym floating around in documents or newsgroups about XP Embedded that is likely what it means.

HORM provides the ability to resume an EWF-protected system from a hibernation file (hiberfil.sys) each time a machine is restarted instead of performing a full OS boot.  This greatly improves the cold-boot startup time of machines.  Here are a few key points about HORM:

• You must protect all partitions on your volume with EWF in order for HORM to work correctly
• You must use EWF RAM or RAM Reg overlay types in conjunction with HORM
• Ordinarily, NTLDR will check the header/signature of hiberfil.sys when the system begins the boot process in order to protect against a stale orphaned hiberfil.sys being booted.  If a stale hiberfil.sys is detected, NTLDR will show a menu asking if you want to continue to resume or discard the hiberfil.sys and perform a full boot.  You can create a file named resmany.dat (any size, any format) on the root of the boot partition (typically c:) to suppress this check and allow your device to resume without any user interaction.
• You must make sure to use the EWF NTLDR with HORM.  EWF NTLDR is the only boot loader that has the logic to search for resmany.dat and skip the hiberfil.sys header check.
• There are useful help docs describing how to implement HORM on your device, you can check them out here.
• One thing not covered in the documentation is how to enable HORM directly from Target Designer.  You can create an additional file resource that will copy resmany.dat to the root of your image partition or simply add it to the image after you do a build inside of Target Designer.  Then, assuming you have enabled hibernation in your power management component and configured EWF to run on startup, you will be able to immediately create your hiberfil.sys after your image finishes running through first-boot agent (FBA).
• If you are using Winlogon and include the settings in the UI Core component you will be able to hibernate via the start menu.  If not, you can include the XPE Power Management tool (xpepm.exe) and run xpepm -hibernate from a cmd prompt to create your hiberfil.sys after you launch the apps that you want to run each time you resume.

I encourage you all to take a look at HORM as you start exploring XPE SP2.  Please let us know if you run into any problems or have any questions.

I got a question from a customer this week asking how they could modify the default installation path in their MSI-based setup package based on a value they wanted to retrieve from the registry.  Typically this kind of modification is desired if your setup shares files/components with another MSI, and that other MSI can be installed to non-default locations by another setup package.  The steps to accomplish this are roughly the following.  Please note that I am basing this algorithm on how we accomplish this inside of Visual Studio setup (I also described what happens behind the scenes in VS setup in more detail here).  There may be alternative ways to accomplish the same result.

1. Create a new entry in the AppSearch table that contains the Signature_ you want to search for and a specific Property name that will store the data you retrieve
2. Create an entry in the RegLocator table that has a Signature_ column name that matches the Signature_ column name you added to the AppSearch table in step 1 above and that contains the key/value you want to retrieve and use if it exists on the user's system
3. Create an entry in the CustomAction table that has a Target value that matches the Property column name you added to the AppSearch table in step 1 above (and is in square brackets since this is an MSI property and it needs to be referenced in square brackets to resolve correctly here), and has a Source name that matches the name of the directory in the Directory table that you want to change the default installation path for
4. Add an entry to the InstallExecuteSequence table that has an Action column name that matches the name of the custom action added in step 3 above and has a Condition column name that matches the Property column name you added to the AppSearch table in step 1 above.  This will ensure that you will only try to change the installation directory if the registry value you are searching for exists on the user's system, and your MSI will use the default installation directory if the registry value is missing.

Rob Mensching wrote a blog entry a while back that explains some reasons why you should not use script-based custom actions in your setup.  I encourage you all to read it if you haven't yet, and I also strongly encourage you to heed his recommendations if at all possible.

I can personally relate to one of his explanations as well.  Reason #3 on his list talks about anti-virus programs.  When we shipped Visual Studio .NET 2002 we started getting reports of seemingly random failures during setup from our product support team.  After some detailed analysis we found that many of these failures were being caused by overly aggressive anti-virus programs that were blocking scripts from running even as part of custom actions during VS setup.  We scrubbed our custom actions before shipping Visual Studio .NET 2003 to re-write or eliminate the script-based custom actions to avoid these failures, and we were able to eliminate a fairly high support call generator.

Question:

I have a system with Windows Vista and have been using Media Center to watch DRM-protected content for a while.  Recently, I upgraded some hardware on my system, and now I can no longer view any DRM-protected content in Media Center.  After some web searches, I found one of your old blog posts that describes a similar type of error message in Update Rollup 2 for Windows XP Media Center Edition 2005.  However, that post and the knowledge base article it refers to appear to be specific to older versions of Windows.

I have read that some types of hardware upgrades can cause DRM to stop working in Windows, and I suspect that is what is happening to me.  How can I reset DRM on my system so that I can view protected content inside of Windows Vista Media Center again?

Answer:

The knowledge base article linked in that old blog post (located at http://support.microsoft.com/?kbid=891664) contains information that is applicable to Windows Vista as well as older versions of Windows, but it does not specifically state that it applies to Windows Vista.

According to this knowledge base article, you can reset DRM by deleting the files in the DRM folder on your system (but make sure to not delete the DRM folder itself because that can cause other problems on your system).

The default location of the DRM folder in Windows Vista is c:\ProgramData\Microsoft\Windows\DRM, but it might not be in the same location on every system.  To reliably determine the location of the DRM folder on your system, you can look up the data in one of the following registry values:

For 32-bit versions of Windows Vista:

[HKEY_LOCAL_MACHINE\Software\Microsoft\DRM]
DataPath

For 64-bit versions of Windows Vista:

[HKEY_LOCAL_MACHINE\Software\WOW6432Node\Microsoft\DRM]
DataPath

Note - the DataPath value is in binary format, so you will have to double-click on the DataPath value in regedit.exe and look at the right-hand column of the Edit Binary Value dialog box that appears to see the plain text version of the path.

I was talking recently with a colleague who works on the .NET Framework setup and Windows Installer technical support team here at Microsoft.  He told me about a set of steps that his team typically has customers try when they call in to report failed installations.  I wanted to post these steps here in case they are helpful to anyone else struggling to get an application installed.

This set of steps allows you to easily find all services that are installed on your system and temporarily disable them so they cannot interfere with installation processes.  It also allows you to identify and temporarily disable programs that are scheduled to start every time the system reboots.  The System Configuration tool (also known as MSConfig) allows you to manage these and other settings.

I recommend trying the following steps in cases where a product fails to install on your system and you've already tried other workarounds posted on my blog and elsewhere to attempt to resolve the issue:

1. Click on the Start menu, choose Run, type msconfig and click OK
2. In the System Configuration tool, click on the Services tab
3. Check the box labeled Hide all Microsoft services
4. Click the Disable All button to disable all non-Microsoft services
5. In the System Configuration tool, click on the General tab
6. Click the Selective startup radio button
7. Uncheck the box labeled Load startup items
8. Click OK to accept all changes in the System Configuration tool
9. Reboot for the changes to take effect
10. Attempt to install the application that previously failed
11. Re-run the System Configuration tool and re-enable the services that you disabled in step 4 above

In many cases, the above steps will allow a previously failing setup package to install successfully.  Hopefully they will be useful to you as well if you find yourself in this situation.

Question:

I have seen your previous blog posts that describe how to detect the presence of the Visual C++ 2005 redistributable package and the Visual C++ 2008 redistributable package.  I am creating an installer that requires the Visual C++ 2010 runtime files.  How can I detect the presence of the Visual C++ 2010 redistributable package?

Answer:

Unlike the Visual C++ 2005 and 2008 redistributable packages, there are registry keys that can be used to detect the presence of the Visual C++ 2010 redistributable package.

Visual C++ 2010 redistributable package detection registry values

• Visual C++ 2010 Redistributable Package (x86)
  
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\x86]
  Installed = 1 (REG_DWORD)

• Visual C++ 2010 Redistributable Package (x64)
  
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\x64]
  Installed = 1 (REG_DWORD)

• Visual C++ 2010 Redistributable Package (ia64)
  
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\VC\VCRedist\ia64]
  Installed = 1 (REG_DWORD)

Alternatively, like in past releases of the Visual C++ redistributable package, you can use an algorithm like the one I described in my previous blog posts to detect the presence of the Visual C++ 2010 redistributable package on a system:

1. Call the MsiQueryProductState API
2. Pass in the product code for the package that you want to detect based on the list below
3. Check the return value of this API.  If it is anything other than INSTALLSTATE_DEFAULT, the package is not yet installed

Visual C++ 2010 redistributable package product codes

• Visual C++ 2010 Redistributable Package (x86) - {196BB40D-1578-3D01-B289-BEFC77A11A1E}
• Visual C++ 2010 Redistributable Package (x64) - {DA5E371C-6333-3D8A-93A4-6FD5B20BCC6E}
• Visual C++ 2010 Redistributable Package (ia64) - {C1A35166-4301-38E9-BA67-02823AD72A1B}

Visual C++ 2010 SP1 redistributable package product codes

• Visual C++ 2010 SP1 Redistributable Package (x86) - {F0C3E5D1-1ADE-321E-8167-68EF0DE699A5}
• Visual C++ 2010 SP1 Redistributable Package (x64) - {1D8E6291-B0D5-35EC-8441-6616F567A0F7}
• Visual C++ 2010 SP1 Redistributable Package (ia64) - {88C73C1C-2DE5-3B01-AFB8-B46EF4AB41CD}

<update date="4/12/2011"> Added product codes for Visual C++ 2010 SP1 redistributable packages. </update>

I've posted an updated version of the .NET Framework cleanup tool that now contains an option to remove the .NET Framework 3.5 (in addition to 1.0, 1.1, 2.0 and 3.0).  I also added some additional information to be removed when uninstalling the .NET Framework 1.1 (thanks to this comment on one of my other blog posts).

You can use the following links to find more information about the .NET Framework cleanup tool and download it if you need it on your system:

• Information about using the cleanup tool - http://blogs.msdn.com/astebner/archive/2006/05/30/611355.aspx
• Link to the cleanup tool - http://astebner.sts.winisp.net/Tools/dotnetfx_cleanup_tool.zip
• Alternate link to the cleanup tool in case the first link does not work - http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog_Tools/dotnetfx_cleanup_tool.zip

Note - at the time that I am writing this blog post, the .NET Framework 3.5 is still only a beta, so currently the cleanup tool is only able to remove the beta 1 and beta 2 versions of the .NET Framework 3.5.  I will update the tool in the future when future builds of the .NET Framework 3.5 are released publicly.

<update date="5/19/2008"> Added an alternate download location for the cleanup tool in case the first site is down. </update>

I have heard from a couple of customers who have uninstalled beta versions of Visual Studio 2005 and then installed the final release.  After installation finished, they saw a small error dialog that looks like the following when trying to launch the Visual Studio 2005 IDE:

Pressing OK on this dialog dismisses the IDE and VS 2005 is not usable.

There are a couple of cases where registry data can be orphaned on the machine that causes this type of error.  Unfortunately, because this data is written by a custom action and there are some "interesting" conditions on that cusotm action in the VS MSI, running a repair of VS 2005 will not correctly fix the registry values that control this functionality.

The following steps can be used to resolve this Invalid license data error message:

1. Uninstall the Visual Studio 2005 product that you have installed.  You only have to uninstall the main Visual Studio product entry in Add or Remove Programs, and you can leave the other pieces installed by Visual Studio setup (such as the .NET Framework 2.0, MSDN, SQL Express, etc) alone.  The product name in Add or Remove Programs that you want to uninstall is dependent on the VS 2005 edition you have installed.  For example, for the English Professional edition, the product name will be "Microsoft Visual Studio 2005 Professional - ENU"
2. Click on Start, choose Run and type cmd
3. Copy and paste each of the following commands into the cmd prompt to clean up orphaned Visual Studio licensing data in your registry: 
   reg delete HKCR\Licenses\17A13F5F-2dE4-4691-B332-83CA4CC38935 /f
   reg delete HKCR\Licenses\2F1682F3-6A3C-4545-AF41-6836A22276CF /f
   reg delete HKCR\Licenses\2FE88699-A1AF-410D-8049-1CB6BA8F8FF2 /f
   reg delete HKCR\Licenses\5BCBC240-27DF-49C1-8C1C-27B8463009A9 /f
   reg delete HKCR\Licenses\895E2152-C3F9-4C49-968B-15B08ADA0F37 /f
   reg delete HKCR\Licenses\95C63E85-8244-4D86-8327-579B85EC154C /f
   reg delete HKCR\Licenses\BA32367F-28F8-4AEA-848D-95AE438B3B9C /f
4. If you are installing on a 64-bit OS, copy and paste each of the following commands into the cmd prompt to clean up orphaned Visual Studio licensing data in your registry:
   reg delete HKCR\Wow6432Node\Licenses\17A13F5F-2dE4-4691-B332-83CA4CC38935 /f
   reg delete HKCR\Wow6432Node\Licenses\2F1682F3-6A3C-4545-AF41-6836A22276CF /f
   reg delete HKCR\Wow6432Node\Licenses\2FE88699-A1AF-410D-8049-1CB6BA8F8FF2 /f
   reg delete HKCR\Wow6432Node\Licenses\5BCBC240-27DF-49C1-8C1C-27B8463009A9 /f
   reg delete HKCR\Wow6432Node\Licenses\895E2152-C3F9-4C49-968B-15B08ADA0F37 /f
   reg delete HKCR\Wow6432Node\Licenses\95C63E85-8244-4D86-8327-579B85EC154C /f
   reg delete HKCR\Wow6432Node\Licenses\BA32367F-28F8-4AEA-848D-95AE438B3B9C /f
5. Re-install the Visual Studio 2005 product that you uninstalled in step 1 above

After doing this, the license data should be recreated and correct and allow you to launch the VS 2005 IDE.

<update date="10/25/2006"> Added some more licensing registry values and a new section for 64-bit registry values that need to be removed </update>

<update date="8/27/2009"> Fixed broken link to image. </update>

Note - the issue described in this blog post was originally presented as an issue on Windows XP SP2.  However, it can also affect .NET Framework 1.0 and 1.1 installation on any OS released after the .NET Framework 1.0 and 1.1 shipped - specifically, I have seen reports of this issue on Windows Vista.  The steps listed here are applicable to this type of install failure on other newer OS's like Windows Vista and not just Windows XP SP2.  

I was contacted by a customer last week who could not get the .NET Framework 1.1 to install correctly.  It reported an error while registering System.EnterpriseServices.dll just like I describe in this post.  In the end, the customer discovered that the system locale of the computer was set to Maltese, and he was able to install the .NET Framework by temporarily changing the system locale back to English.

I did a little research, and found that there is a bug in the .NET Framework that causes it to not work correctly when the default system locale is set to a language that the .NET Framework does not recognize.  This bug has been fixed in the .NET Framework 1.0 SP3 and 1.1 SP1.  However, this bug causes the initial installation of the .NET Framework to fail and rollback, and you cannot install the service pack without first getting the product installed (unless you use a method like I describe here, which will work but is not "officially" supported).

With the release of Windows XP SP2, Microsoft shipped Enabling Language Kits (ELKs) for 25 new locales (click here for a complete list and a nice description of what features ELKs provide).  Because of the bug in the .NET Framework that I described above, if a computer running XP SP2 has the system locale set to one of these 25 new locales, installation of the .NET Framework will fail while trying to register System.EnterpriseServices.dll (which happens to be the first time that managed code gets run during setup and therefore is the first time the bug is hit).

If you are running into this bug on your Windows XP SP2 computer, you can use the following steps to work around this bug in the .NET Framework and get it installed:

1. From the Start menu, type intl.cpl in the Run box or go to Control Panel and choose the Regional and Language Options item
2. Click the Advanced tab
3. Change the language in the dropdown box labeled "Select a language to match the language version of the non-Unicode programs you want to use:" to English (this setting represents the system locale for the computer)
4. Check the box labeled "Apply all settings to the current user account and to the default user profile"
5. Click OK
6. Restart
7. Install the .NET Framework 1.0 or 1.1
8. Install .NET Framework 1.0 SP3 or 1.1 SP1
9. Return to the Regional and Language Options control panel and change the language in the Advanced tab back to the original setting

For reference, here is what the Advanced tab of the Regional and Language Options control panel looks like.  This screenshot is from my laptop, where I was able to reproduce the failure to install the .NET Framework by changing my system locale to Welsh (one of the 25 new ELKs included in XP SP2):
 

<update date="7/26/2005> As Michael Kaplan points out, the underlying bug affects both the .NET Framework core setup and the .NET Framework service pack setup.  Once a computer has .NET Framework 1.0 + SP3 and/or 1.1 + SP1, the bug will not affect any future .NET Framework service packs.  In addition, the bug can happen if your computer has a default user locale set to one of the new ELK languages, not just a default system locale. </update>

<update date="4/17/2008"> Added a note indicating that the issue in this post can affect the .NET Framework 1.0 and 1.1 setup on Windows Vista and not just Windows XP SP2 </update>

I received an email yesterday from an individual who had just installed the latest Windows Installer Platform SDK and had read a previous blog post that I wrote about using msi.chm for Windows Installer help information, but was unable to find msi.chm on his system.  I took a look on our internal products server and couldn't find msi.chm there either, so I decided to go to the Platform SDK site and figure out what was going on.  What I found is that I was basing the information in that blog entry about msi.chm on what appears to be an older version of the Platform SDK that I had downloaded a while ago and then just copied msi.chm off to a separate location.

I tried out a new download of the Windows Installer part of the Platform SDK, and it appears they have re-organized the help documentation for the entire SDK.  Instead of having standalone CHM files for each product in the SDK, there is now a unified Platform SDK help collection and each individual product plugs in and registers an HXS (compiled help) file.

So what I had to do was launch the Platform SDK Documentation link on the Start menu after installation of the SDK.  From there I was able to use the index and search that I normally use in my old copy of msi.chm, and as an added bonus there are updated topics for Windows Installer 3.0 and some of the incorrect info in my old version of msi.chm have been fixed.

Sorry for any confusion I created in my original post....

Hey, I'm happy to say that the .NET Framework 2.0 is finally finished, and the official RTM build (2.0.50727.42) is available for download on the Microsoft Download Center.  Check out this location for a full list of .NET Framework 2.0 products that are available.  Here are some of the most commonly requested downloads:

• .NET Framework 2.0 redistributable (x86)
• .NET Framework 2.0 SDK (x86)
• .NET Framework 2.0 redistributable (x64)
• .NET Framework 2.0 SDK (x64)
• .NET Framework 2.0 redistributable (ia64)
• .NET Framework 2.0 SDK (ia64)

A couple of important notes here:

1. The .NET Framework 2.0 SDK requires that you install the .NET Framework 2.0 redistributable first, so if you want the SDK make sure to download both
2. The .NET Framework 2.0 redistributable is a language-neutral package.  Setup UI will appear in the language of the OS you are running setup on (more setup packaging details are here if you are interested).  The resources inside of the package are English only.  There will be language packs available soon that contain non-English product resources.
3. The .NET Framework 2.0 SDK is English only.  Non-English languages will be available soon.