I have heard from a few customers since the release of the .NET Framework 4 who have installed the .NET Framework 4 on Windows Vista or higher and setup reported success, but they see an error when running the .NET Framework setup verification tool.  I wanted to describe this scenario in a bit more detail, including how to diagnose whether or not your computer is running into this issue based on the setup log files.

How to quickly tell if this blog post might apply to you

Before reading this whole post, here is a quick way you can check whether or not you are likely to be encountering the issue described below:

1. Your OS was Windows Vista, Windows Server 2008 or Windows 7.  This particular issue does not affect Windows XP or Windows Server 2003.
2. You installed the .NET Framework 4 and setup reported success, but you cannot use .NET Framework 4 applications on your computer afterwards.
3. The file %windir%\system32\mscoree.dll and/or %windir%\syswow64\mscoree.dll has a file version of 2.0.* instead of 4.0.* (and you have rebooted your computer after installing the .NET Framework 4 to make sure that any files that were in use during installation have had a chance to be updated).

Symptoms of the problem

In the cases I’ve seen so far, the .NET Framework setup verification tool reported an error like the following when it tried to run a .NET Framework test application that is bundled with it:

****ERROR**** Process 'Netfx40TestApplication.exe' exited with return code -2146232576

This return code translates to 0x800131700, which is a .NET Framework common language runtime (CLR) error code that means “Failed to load the runtime.”  In other words, this return code means that this version of the .NET Framework runtime failed to load at all on this computer.

Further investigation on the computers that exhibited this behavior showed that the file mscoree.dll (which is located in %windir%\system32 and/or %windir%\syswow64) had a version number of 2.0.*.  This file is shared by all versions of the .NET Framework, and it should always have a version of at least 4.0.* after installing the .NET Framework 4.  If this file is not updated to version 4.0.*, the CLR loader will be unable to load the .NET Framework 4, and it will cause the type of failure in the .NET Framework verification tool that I described above.

Gathering more detailed information from .NET Framework setup log files

I wasn’t sure how a computer could be in a state where .NET Framework 4 setup reported a successful installation but yet mscoree.dll was still versioned 2.0.*.  I had the customers use the instructions in this blog post to gather their .NET Framework setup log files, and I started looking at the logs to narrow this issue down further.

In the cases I’ve seen so far, I found an error like the following in the log file named Microsoft .NET Framework 4 Setup_*.html:

Exe (C:\Users\myusername\AppData\Local\Temp\Microsoft .NET Framework 4 Setup_4.0.30319\Windows6.1-KB958488-v6001-x64.msu) failed with 0x80240017 - (null).

The .msu file listed in the above error message is one of the ones that are responsible for updating mscoree.dll to version 4.0.* on Windows Vista and later versions of Windows.  Return code 0x80240017 means that the .msu file is not applicable on the computer it is being installed on.  This type of return code can occur for several different reasons:

1. The .msu is for an earlier or later OS version or service pack level than what is currently on the computer
2. The .msu is for a different processor architecture than the OS running on the computer
3. The .msu is already installed
4. The OS update installation engine is in a broken state that prevents the installation of any OS updates (.msu files)
5. The OS is a pre-release version of Windows 7.  See this blog post for more details about this case.

.NET Framework 4 setup prevents cases #1 and #2 from happening behind the scenes, but it cannot prevent cases #3, #4 or #5.  To complicate things further, it is not possible to reliably distinguish from this return code which of the cases is the actual cause of the return code.  Even worse, case #3 is a case that should be treated the same as a successful installation of this .msu as opposed to a failure.

As a result, the .NET Framework 4 setup ignores this error and treats it as a successful installation of this .msu (case #3).  This is why you will see information like the following later in the log file:

Error 0x80240017 is mapped to Custom Error: Success

Narrowing down the root cause based on the log files

Because mscoree.dll was not updated like it should have been on the affected computers, I made an educated guess that the customers who contacted me were running into case #4 on their computers.  I was able to confirm this in the following ways:

1. Looking at the log files named %windir%\WindowsUpdate.log and %windir%\logs\cbs\cbs.log (both of which are collected by the log collection tool linked above).  In the cases I’ve seen so far, one or both of these logs showed errors while trying to evaluate applicability and/or install OS updates.  These errors affected the .NET Framework 4 .msu file as well as other OS updates that the customer had attempted to install.
2. Trying to manually install an OS update from Windows Update or by downloading it and running it directly.  In the cases I’ve seen so far, attempting to install any OS update failed just like the .NET Framework 4 .msu file failed.

Possible solutions for this type of error

1. In some cases, it can help to run SFC to repair the files that are installed as a part of Windows.  You can find steps that explain how to do this in this knowledge base article.
   
   
2. If SFC does not help, the System Update Readiness Tool might help repair the computer so that OS updates will install again.  I’ve posted a set of steps I’ve had success using with this tool in some cases in the past in this blog post.
   
   
3. Peter Marcu has posted a few additional suggestions on his blog for this type of issue as well.
   
   
4. Unfortunately, if the above suggestions do not help, the only other way that I've found to solve this type of OS update installation error is to repair Windows. 

<update date="12/30/2010"> Added a note about pre-release versions of Windows causing this error as well. </update>

<update date="7/27/2011"> Added a note about using SFC to repair Windows files, as suggested in Peter Marcu's blog. </update>

<update date="11/8/2011"> Added a direct link to Peter Marcu's blog post about this issue. </update>

Question:

I used the instructions and the cleanup tool in this blog post to remove all versions of the .NET Framework from my computer, and now I want to re-install them.  Do I need to re-install them in any specific order?

Answer:

In general, the versions of the .NET Framework allow you to install in any order you choose.  However, I recommend installing in reverse order from newest to oldest, like this:

1. .NET Framework 4
2. .NET Framework 3.5 SP1 (this will install the .NET Framework 2.0 SP2 and 3.0 SP2 behind the scenes so you do not have to install them separately)
3. .NET Framework 1.1 (if you have any programs installed that need it, this blog post can help you decide whether or not you need it)

Most programs do not specifically require the .NET Framework 1.0 so I didn't list it above.  If you do need the .NET Framework 1.0, you will have to install it before installing the .NET Framework 4 because .NET Framework 4 setup blocks future installation attempts for the .NET Framework 4.  If you need the .NET Framework 1.0, I recommend installing in this order:

1. .NET Framework 3.5 SP1 (this will install the .NET Framework 2.0 SP2 and 3.0 SP2 behind the scenes so you do not have to install them separately)
2. .NET Framework 1.1 (if you have any programs installed that need it, this blog post can help you decide whether or not you need it)
3. .NET Framework 1.0 (if you have any programs installed that need it, this blog post can help you decide whether or not you need it)
4. .NET Framework 4

Even though it is a little counter-intuitive, there are a couple of reasons that I recommend installing in reverse order:

• To help avoid some possible setup bugs in older versions of the .NET Framework – there are a couple of setup bugs (like this and this) in older versions of the .NET Framework that are fixed in service packs and later versions.  Installing a later version of the .NET Framework first will update some files that are shared by all versions of the .NET Framework, and that will allow you to avoid these bugs when installing older versions of the .NET Framework.
• To minimize the number of separate downloads and installs – if you install the .NET Framework 3.5 SP1 first, it will automatically install the .NET Framework 2.0 SP2 and 3.0 SP2 for you, so you don’t need to install them separately.  Also, if you install older versions of the .NET Framework 2.0 and 3.0 before installing the .NET Framework 3.5 SP1, the 3.5 SP1 installer will automatically uninstall them as a part of its install process.  That means you will just end up wasting time if you install the .NET Framework 2.0 and 3.0 before installing the .NET Framework 3.5 SP1.

<update date="1/31/2011"> Added a separate set of installation instructions for cases where the .NET Framework 1.0 is required because .NET Framework 4 setup prevents the .NET Framework 1.0 from being installed after it. </update>

My colleague Shawn Hargreaves wrote a helpful blog post last week that gives more detailed information about how to use isolated storage APIs in an XNA Game Studio Windows game.  It includes some settings that you can change in the Visual Studio IDE so that you can use the GetUserStoreForApplication API during debugging without needing to deploy your game using ClickOnce.

If you are using isolated storage APIs in a Windows game, I strongly encourage you to check out Shawn’s post at http://blogs.msdn.com/b/shawnhar/archive/2010/12/16/isolated-storage-windows-and-clickonce.aspx for more information to help you during development and debugging of your game.

A little while ago, I wrote a blog post with a list of steps that you can use to create native resource DLLs so that you can localize the title of your Windows Phone game created with XNA Game Studio 4.0.  Today, I found a blog post about a tool that automates the process of creating these native resource DLLs.  This tool provides 2 really nice benefits:

1. It eliminates the requirement that you have to build your game from an edition of Visual Studio 2010 that supports both C# and C++ development (the VS 2010 Professional or better editions).  In other words, this allows you to build a game with a localized title in the free Visual Studio 2010 Express for Windows Phone edition.
2. It greatly simplifies the number and complexity of the steps required to enable title localization for your game.

You can find the tool in this blog post.  Here is a set of steps that use this tool that you can use in place of the ones I posted in my earlier blog post to enable title localization for your Windows Phone game created with XNA Game Studio 4.0:

Step 0 – Create a Windows Phone game project

1. Start Visual Studio 2010 or Visual Studio 2010 Express for Windows Phone.
2. Click on File | New | Project..., select Visual C# | XNA Game Studio 4.0 and choose Windows Phone Game (4.0).

Step 1 – Create native resource DLLs using the Windows Phone 7 Title Localizer tool

1. Download the Windows Phone 7 Title Localizer tool from the link at the end of the blog post at http://patrickgetzmann.wordpress.com/wp7-localize/.
2. Run the Windows Phone 7 Title Localizer tool.
3. Enter your language-neutral title strings.
4. Enter your translated title strings or use the Translate button in the tool to automatically translate the strings using the Bing translator engine.
5. Click the Save DLLs button to create native resource DLLs that contain the strings you have provided.

Step 2 – Add native resource DLLs to your Windows Phone game project

Note - the name of the native resource DLL is important in this scenario.  It must be named AppResLib.dll, and the localized versions must be named AppResLib.dll.*.mui.  If they are named differently, your game will be rejected by the Windows Phone Marketplace certification process.

1. Right-click on your Windows Phone game project in the Visual Studio solution explorer, click Add | Existing Item...
2. Browse to the folder that you saved the DLLs to in step 2 above, select the file named AppResLib.dll, then click the Add button.
3. Select each of the files named AppResLib.dll.*.mui in the same folder, then click the Add button.
4. For each of the AppResLib.dll* files that you have added to your Windows Phone game project, set the Build Action property to None and the Copy to Output Directory property to Copy if newer.  This will make sure that each of these files gets packaged into the XAP file that is created when you build your Windows Phone Game project.

Step 3 – Update your Windows Phone game to load title strings from the resource DLLs

Update the application title by doing the following:

1. In your Windows Phone Game project, open the file Properties\AssemblyInfo.cs.
2. Remove the AssemblyTitle entry.
3. Add an AssemblyTitleAttribute entry that looks like this:
   
   [assembly: AssemblyTitleAttribute("@AppResLib.dll,-100")]

Update the tile title by doing the following:

1. Right-click on your Windows Phone Game project in the Visual Studio solution explorer and choose Properties.
2. Click on the XNA Game Studio tab.
3. Change the Tile title value to look like this:
   
   @AppResLib.dll,-200

The tile title is the name that is displayed if you click and hold on your application/game in the Windows Phone OS and choose to pin it to the start menu.  There is some additional information about these properties and how to configure them in XNA Game Studio games in this documentation topic.  Depending on the scenarios you want to support for your game, it may not be necessary to create separate strings for your application title and tile title.  If you plan to use the same string for both, you do not need to create separate entries in the string table in each of your native resource DLLs in the instructions above.

Step 4 – Rebuild your Windows Phone game solution

Rebuild the solution that contains your Windows Phone Game project.

<update date="1/18/2011"> Added a warning about the naming of the DLL needing to exactly match what is listed in the documentation. </update>

Rob Mensching announced on his blog last week that WiX v3.5 is now in escrow mode, which means that there were zero active bugs when the v3.5.2325 build was produced, and the final release of WiX v3.5 will be happening very soon.  If no showstopper bugs are found and fixed, this build will be the final build of WiX v3.5.

If you are using WiX to create Windows Installer packages for your products, I strongly encourage you to upgrade to this build of WiX v3.5 and help the WiX virtual team validate that this build is ready to be declared the final WiX v3.5 build.  Here are a couple of links to help get you started:

• Download location for the WiX v3.5 escrow build (v3.5.2325) - http://wix.sourceforge.net/releases/3.5.2325.0/
• WiX bug reporting site - http://sourceforge.net/tracker/?group_id=105970&atid=642714
• WiX discussion lists - http://wix.sourceforge.net/mailinglists.html#wix-users