I have posted several items on my blog in the past about the .NET Framework cleanup tool.  The information has ended up becoming more scattered and difficult to find over time, so I decided to create a centralized introductory topic.

You can find the .NET Framework cleanup tool user's guide at http://blogs.msdn.com/astebner/pages/8904493.aspx or http://go.microsoft.com/fwlink/?LinkID=121918.

The user's guide includes the following information:

• Caveats to review before using the .NET Framework cleanup tool
• Where to download the tool
• Versions of the .NET Framework that can be removed with the tool
• How to run in silent mode
• How to run in unattended mode
• Exit codes returned by the tool
• Log files created by the tool

As changes are made to the .NET Framework cleanup tool in the future, I will keep the user's guide up-to-date at the location at the link above so information about this tool can be found at a consistent place from now on.

I have heard from a couple of customers who ran into issues installing the .NET Framework 3.5 and/or the .NET Framework 3.5 SP1 on one of the following OS types:

• Checked (also known as debug) builds of Windows Vista and/or Windows Server 2008
• Pre-release builds of Windows Vista and/or Windows Server 2008

One of these customer reports can be found in this forum post.  I wanted to describe this scenario in more detail in case anyone else runs into a similar issue in the future.

Description of the issue

The .NET Framework 3.5 and 3.5 SP1 install service packs for the .NET Framework 2.0 and the .NET Framework 3.0 behind the scenes.  On Windows Vista and Windows Server 2008, the .NET Framework 2.0 and 3.0 service packs are installed as OS updates.  These OS updates are marked to only install on the final release versions of Windows Vista and Windows Server 2008.  That means that they will not allow you to install them on checked builds of these OS's, and they will also not allow you to install them on pre-release versions of these OS's.

Here is the exact list of .NET Framework 3.5 installation scenarios that will fail on checked builds of the OS or pre-release builds of the OS:

• Installing the .NET Framework 3.5 on the original release of Windows Vista (but not Windows Vista SP1 or later)
• Installing the .NET Framework 3.5 SP1 on the original release of Windows Vista or Windows Vista SP1
• Installing the .NET Framework 3.5 SP1 on Windows Server 2008

However, installing the original release of the .NET Framework 3.5 on Windows Vista SP1 or Windows Server 2008 will not fail due to this issue.  This is because Windows Vista SP1 and Windows Server 2008 already include the .NET Framework 2.0 SP1 and 3.0 SP1 as OS components, so .NET Framework 3.5 setup does not need to install any OS updates on those systems.

How to work around the issue

Unfortunately, there is not a workaround that will allow you to install on a checked build or a pre-release build of Windows Vista or Windows Server 2008.  Instead, you will need to install a final release build of Windows Vista or Windows Server 2008, then re-run .NET Framework 3.5 or 3.5 SP1 setup.

How to diagnose the issue

If you try to install in one of the above configurations, you will see the following error in the .NET Framework 3.5 or 3.5 SP1 log file named %temp%\dd_dotnetfx35install.txt:

[08/08/08,11:11:11] Microsoft .NET Framework 2.0SP1 (CBS): ***ERRORLOG EVENT*** : Error: Installation failed for component Microsoft .NET Framework 2.0SP1 (CBS). MSI returned error code 1.

Error code 1 for Windows Vista or Windows Server 2008 OS update packages means that the package is not applicable on the current OS.

Important note about error code 1 during .NET Framework 3.5 or 3.5 SP1 setup

Please note that this blog post only describes one possible cause of error code 1 during .NET Framework 3.5 or 3.5 SP1 installation.  If you are not running a checked build of Windows or a pre-release version of Windows, then the issue described here is not the cause of the installation failure on your system.

If you are running into error code 1 but are not running a checked or pre-release build of Windows, then it typically helps to review the .NET Framework 3.5 log files to try to learn more about the root cause of the issue.  You can find more information about what log files are produced by .NET Framework 3.5 setup in this blog post, and there is information in this blog post that describes options for reporting installation failures back to Microsoft for additional investigation.

The logs that are typically the most useful in diagnosing error code 1 are the following:

• %temp%\dd_dotnetfx35install.txt
• %windir%\logs\cbs\cbs.log
• %windir%\WindowsUpdate.log

Question:

I have downloaded both versions of the sample .NET Framework version detection code (described here and here), and I am trying to compile it to test it out on my system.  However, I am running into issues trying to create a Visual Studio project that will correctly build the sample code.  What do I need to do to get this sample code to compile on my system?

Answer:

You should be able to use the following steps to create a project and compile the sample .NET Framework detection code using either Visual Studio 2005 or Visual Studio 2008:

1. Start Visual Studio 2005 or Visual Studio 2008 (the steps are equivalent in both versions of VS)
2. Click on the File menu, choose File | New | Project...
3. In the Visual C++ node, select the Win32 project item, provide a name and click OK
4. In the Win32 Application Wizard dialog, click Next on the Overview screen
5. Select Windows Application on the Application Settings screen (but do not change any of the other settings) and click Finish
6. Right-click on your project in the Visual Studio Solution Explorer and choose Properties
7. In the property pages, change the Configuration drop down at the top from Active (Debug) to All Configurations
8. Go to Configuration Properties | C/C++ | Precompiled Headers and change the Create/Use Precompiled Header from Use Precompiled Header (/Yu) to Not Using Precompiled Headers
9. Click OK to dismiss the property pages
10. Replace the contents of your main CPP file with the contents of the file from my blog post (the original detection sample, or the enhanced sample that does some additional checks behind the scenes)
11. Save all of the project files
12. Build the project

Note - while testing the above steps, I noticed that the sample code was generating several warnings during the build process.  I fixed these and posted updated versions of both samples that will build by default without any warnings.

Sara Ford posted an item on her blog this week that I want to link to here to hopefully help raise visibility.  She has written a book called Microsoft Visual Studio Tips that compiles a collection of items from the Visual Studio tip of the day series on her blog.  The book is currently available for pre-order.

The really cool thing about this book is that Sara is donating 100% of her book author royalties to establish a scholarship fund to help students from her home town attend college.  Those who follow Sara's blog know that her home town is Waveland, Mississippi, which was devastated by Hurricane Katrina back in 2005 and is still recovering.  This sounds like a great way to give back, so I hope that you'll consider getting a copy of Sara's book and know that you'll be helping to make a difference in a community that has been hit hard by this natural disaster.

As noted earlier today in this post on Soma's blog, the .NET Framework 3.5 SP1 and Visual Studio 2008 SP1 have been released and are now available for download.  Here is a collection of useful links to help you learn more about these service pack releases, download and install them, and troubleshoot installation issues that you might encounter.

SP1 introductory information

• .NET Framework 3.5 SP1 and VS 2008 SP1 overview
• What's new in the .NET Framework 3.5 SP1
• What's new in Visual Studio 2008 SP1

SP1 download links

Important notes - the .NET Framework 3.5 SP1, the VS 2008 Express Edition SP1 packages and MSDN for VS 2008 SP1 are slipstream replacements for the original versions of the .NET Framework 3.5, VS 2008 Express Editions and MSDN for VS 2008.  This means you can directly download and install the SP1 packages without first installing the original versions.

However, the VS 2008 SP1 and Team Foundation Server SP1 packages are traditional service packs that require you to first install the original versions before you will be able to install the SP.

• .NET Framework 3.5 SP1 web download bootstrapper
• .NET Framework 3.5 SP1 full install package
• .NET Framework 3.5 SP1 language packs web download bootstrapper (choose the desired language in the drop-down and click the Change button to navigate to the appropriate download page)
• Visual Studio 2008 SP1
• Visual Studio 2008 Express Editions with SP1 web download bootstrappers
• Visual Studio Team System 2008 Team Foundation Server SP1

SP1 troubleshooting links

• Visual Studio 2008 SP1 pre-release uninstall instructions
• Tool to remove pre-release versions of Visual Studio 2008 SP1
• Visual Studio 2008 and .NET Framework 3.5 log collection tool information
• Visual Studio 2008 and .NET Framework 3.5 log collection tool download location
• Posts on Heath Stewart's blog about Visual Studio 2008 SP1 issues and workarounds

SP1 readme files

• .NET Framework 3.5 SP1 readme
• Visual Studio 2008 SP1 readme
• Visual Studio 2008 Express Editions SP1 readme

.NET Framework 3.5 client profile links

• .NET Framework 3.5 client profile download location (web download bootstrapper)
• .NET Framework 3.5 client profile download location (full install package)
• .NET Framework 3.5 client profile language pack download location
• .NET Framework 3.5 client profile overview
• .NET Framework 3.5 client profile deployment guide

<update date="8/12/2008"> Added links to information about the .NET Framework 3.5 client profile </update>

<update date="8/12/2008"> Added link to download .NET Framework 3.5 SP1 language packs </update>

<update date="8/24/2008"> Added links to .NET Framework 3.5 client profile web download bootstrapper and deployment guide </update>

<update date="9/8/2008"> Updated incorrect link to .NET Framework 3.5 SP1 language packs </update>

Recently, I tried to create a Windows Installer major upgrade for an MSI that I was working on.  This MSI installs assemblies to the GAC and I did not want to change the assembly version for these assemblies in the new MSI.  As a result, I scheduled the RemoveExistingProducts action after the InstallFinalize action in order to avoid the issue described at http://support.microsoft.com/kb/905238.

However, after creating the new version of this MSI and running through a test major upgrade scenario, I found that the assemblies in the GAC were still the ones with the old file versions from the older version from the MSI.  When investigating this issue, I found the following information in the verbose MSI log that explained why the assemblies were not being updated in the GAC like I expected:

MSI (c) (34:24) [11:11:11:111]: skipping installation of assembly component: {A84F2D22-3442-4121-838B-97805DBE8FE7} since the assembly already exists

I was not sure how to fix this, so I asked Heath Stewart for help, and the first thing he asked me to do was look in the MsiAssemblyName table of the new version of my MSI and see what attributes are listed there for each assembly.  When I did that, I found that each assembly had attributes for name, version, culture, publicKeyToken and processorArchitecture.  Heath pointed out to me that what I am trying to do in this scenario is an in-place update of an assembly in the GAC - meaning that the assembly has the same strong name but a different file version.  Windows Installer will not perform an in-place update of an assembly in the GAC unless the fileVersion attribute is set for the assembly in the MsiAssemblyName table of the new MSI.

Now that I knew why these assemblies were not being updated, I had to figure out why the fileVersion attribute was not being included in the MsiAssemblyName table of my MSI and then find a way to add it.  I am using WiX v3.0 to create these MSIs, and I discovered that by default, WiX does not include the fileVersion attribute in the MsiAssemblyName table when it creates MSIs.

It is possible to override the default behavior.  Doing either of the following will cause WiX to include the fileVersion attribute for all assemblies in the MsiAssemblyName table of the MSI:

1. If you are building your MSI by calling the WiX tools directly, you can add the -fv switch when calling light.exe (the WiX linker)
2. If you are building your MSI by using Votive in the Visual Studio IDE or by running MSBuild and passing in a .wixproj file, you can add the following parameter to your .wixproj file:

<SetMsiAssemblyNameFileVersion>True</SetMsiAssemblyNameFileVersion>

After using one of the above options, I rebuilt my MSI and verified that it now contains the fileVersion attribute for each assembly in the MsiAssemblyName table.  Afterwards, I tried a new test of the major upgrade scenario I was working on and found that the assemblies in the GAC were now updated to the new file version as I expected.

For reference, you can find more information about how Windows Installer updates assemblies in this MSDN topic.

We have heard from some customers about problems while using the XNA Game Studio Device Center to add Xbox 360 devices in XNA Game Studio 2.0 and to add Xbox 360 devices and Zune devices in the XNA Game Studio 3.0 CTP (for example, the Connect bugs that have been logged here and here as well as several threads on the forums).  After having no luck reproducing this issue in-house for a long time, we have finally figured out the root cause and I wanted to post more details here in case anyone runs into this issue in the future.

Description of the issue

The specific problem we have seen is the following:

1. Launch the XNA Game Studio Device Center
2. Click the button named Add Device
3. If you are using the XNA Game Studio 3.0 CTP, select the device type (Xbox 360 or Zune)
4. For an Xbox 360:
   
   Enter a device name and click Next
   Enter a 25 character connection code
   
   
5. For a Zune:
   
   Select the name of the Zune that is connected to the computer that you want to add
   
   
6. Click Next to attempt to connect the device

In the problematic cases, after clicking Next, the Device Center will crash with an unhandled exception error dialog as soon as it starts trying to contact the device.  The exception details show that it is a NullReferenceException with the error message "Object reference not set to an instance of an object."

If this error appears, there is no way to add a new device using the Device Center.

How to work around this issue

If you see this type of crash in the XNA Game Studio Device Center, there are a few options we have found that should allow you to recover and successfully add devices in the Device Center UI:

1. Download and install the repair tool that I have posted at http://astebner.sts.winisp.net/Tools/netfx20regtlib.zip.  Installing the MSI in this zip file will repair the incorrectly registered components on your system, and then you can safely uninstall the MSI.
2. Installing the .NET Framework 1.1 will also fix the incorrectly registered components that are causing the problem behind the scenes in the cases we have investigated so far.  You do not need to do this if you have already installed the repair tool in step 1.
3. Manually fix up one of the registry values on your system.  If you choose this option, you need to find the following value using regedit.exe and update the data - in the broken state, Version will be set to 1.a.  You need to change it to 2.0.
   [HKEY_CLASSES_ROOT\Interface\{805D7A98-D4AF-3F0F-967F-E5CF45312D2C}\TypeLib]
   Version = 1.a

How to reproduce this issue

The simplest case we have found that will reproduce this issue is the following:

1. Install Windows Vista or Windows Server 2008
2. Install the .NET Framework 1.1
3. Uninstall the .NET Framework 1.1
4. Install Visual Studio 2005 + 2005 SP1 or Visual Studio 2008
5. Install XNA Game Studio 2.0 or XNA Game Studio 3.0 CTP

The order of the above steps does not really matter - the key thing here that causes the problem is that the .NET Framework 1.1 has been installed and uninstalled on the system.

More details about the root cause

On Windows Vista and Windows Server 2008, installing and then uninstalling the .NET Framework 1.1 will cause all of the .NET Framework type libraries on your system to be left in an incorrectly registered state.  As an example, on a system in the broken state, the IDisposible interface will contain this type library version information:

[HKEY_CLASSES_ROOT\Interface\{805D7A98-D4AF-3F0F-967F-E5CF45312D2C}\TypeLib]
(default) = {BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}
Version = 1.a

However, if you look at the type library registration for mscorlib.tlb (which is the type library represented by the GUID listed above), you will see that it only has version 2.0 registered, not version 1.a:

[HKEY_CLASSES_ROOT\TypeLib\{BED7F4EA-1A96-11D2-8F08-00A0C9A6186D}]
2.0

Even more details about the root cause

The root cause goes even deeper than what is listed above, and is particularly interesting to me because it is related to .NET Framework setup, which I used to work on in a previous role here at Microsoft.

We have not seen this problem on versions of Windows prior to Windows Vista (such as Windows XP or Windows Server 2003).  When I went back to try to figure out why, I realized that this specific uninstall scenario was known to be a problem at the time that the .NET Framework 1.1 shipped.  As a result, the MSI-based installer for the .NET Framework 2.0 adds some artificial reference counts for .NET Framework 1.0 and 1.1 type libraries.  These reference counts prevent the .NET Framework 1.1 uninstall process from unregistering and uninstalling these type libraries, which makes this broken state unreachable on an OS that has the MSI-based version of the .NET Framework 2.0 installed or on an OS that does not have any version of the .NET Framework installed.

Windows Vista and Windows Server 2008 include the .NET Framework 2.0 and 3.0 as OS components, and these OS components are not installed using the MSI-based installers.  The OS components do not add the same artificial reference counts as the MSI-based installer, so that leaves them vulnerable to these type library registration issues.

So far, the only application that I have seen encounter any problems due to this broken state is the XNA Game Studio Device Center, but it is possible that other .NET Framework-based applications could be affected as well.  Using the type library repair tool (workaround #1 above) or re-installing the .NET Framework 1.1 (workaround #2 above) should fix all .NET Framework type library registration on a system.  However, fixing the single IDisposible registry value (workaround #3 above) will only resolve the crash in the XNA Game Studio Device Center - it will not fix the rest of the .NET Framework type library registration on an affected system.

Fortunately, we have identified a code change that we can make in the XNA Game Studio Device Center to prevent it from crashing even in a scenario where the .NET Framework type libraries are incorrectly registered on a system.  This fix will be present in the final release of XNA Game Studio 3.0, so that means that the only susceptible versions should be XNA Game Studio 2.0 and the XNA Game Studio 3.0 CTP.

Earlier this week, a friend of mine let me know about the Windows LIVE Web page translator.  I decided to add the translator tool to my blog since it only requires adding a small script block to my main blog page.  You can now find the translator tool in the left column on all of my blog pages underneath the News heading and the disclaimer.  When you navigate to individual blog posts, you can use the translator tool to have the automatic translation engine attempt to translate the blog post into one of the following languages:

• Arabic
• Chinese (Simplified)
• Chinese (Traditional)
• Dutch
• French
• German
• Italian
• Japanese
• Korean
• Portuguese
• Russian
• Spanish

Of these languages, I only speak French, so I tried it out on a few of my posts for the French language translation engine, and it seems to do a pretty good job.  There are some blocks of text that it doesn't seem to even try to translate, so I'll have to try to figure out how to better tune my writing style to work better for this type of engine in the future.  If you read one of these languages, hopefully this tool will be helpful for you as you browse the content on my blog.

Question:

As described in this blog post, I have been evaluating the beta of the .NET Framework 3.5 SP1 and Visual Studio 2008 SP1.  I ran into some issues running my application on a system with this software installed, so I need to uninstall it.  I have tried to uninstall the .NET Framework 3.5 SP1, but all of the .NET Framework 2.0 assemblies are still at the SP2 level and are not rolled back.  How can I fully uninstall the .NET Framework 3.5 SP1?

Answer:

The .NET Framework 3.5 SP1 is a slipstream replacement for the original release of the .NET Framework 3.5.  It installs the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2 behind the scenes, and 2.0 SP2 and 3.0 SP2 are both slipstream replacements of previous versions of the .NET Framework 2.0 and 3.0.

In order to fully uninstall the .NET Framework 3.5 SP1 and return to the .NET Framework 3.5, .NET Framework 2.0 SP1 and .NET Framework 3.0 SP1, you must use the following steps.  Note that there are different steps on Windows Vista and Windows Server 2008 than on earlier versions of Windows because the .NET Framework 2.0 and 3.0 are OS components on Windows Vista and Windows Server 2008.

How to uninstall the .NET Framework 3.5 SP1 on Windows XP and Windows Server 2003:

1. Go to the Add/Remove Programs control panel
2. Find the product named Microsoft .NET Framework 3.5 SP1 and uninstall it
3. Find the product named Microsoft .NET Framework 3.0 SP2 and uninstall it
4. Find the product named Microsoft .NET Framework 2.0 SP2 and uninstall it
5. Re-install the original release of the .NET Framework 3.5 (which will re-install the .NET Framework 2.0 SP1 and the .NET Framework 3.0 SP1 behind the scenes)

How to uninstall the .NET Framework 3.5 SP1 on Windows Vista and Windows Server 2008:

Note - these steps are not required if you had a beta version of the .NET Framework 3.5 SP1 and plan to upgrade to the final release.  Behind the scenes, the .NET Framework 2.0 SP2 and .NET Framework 3.0 SP2 packages are designed to upgrade older beta versions of the same packages.  These steps are only needed if you are trying to fully remove the .NET Framework 2.0 SP2, .NET Framework 3.0 SP2 and .NET Framework 3.5 SP1 in order to move back to a previous version of the .NET Framework.

1. Go to the Programs and Features control panel
2. Find the product named Microsoft .NET Framework 3.5 SP1 and uninstall it
3. In the Programs and Features control panel, click the link on the left named View Installed Updates
4. In the list of installed updates, look for an item named Update for Microsoft Windows (KB948610) - this is the .NET Framework 3.0 SP2 OS update package
5. Right-click on the item and choose Uninstall
6. In the list of installed updates, look for an item named Update for Microsoft Windows (KB948609) - this is the .NET Framework 2.0 SP2 OS update package
7. Right-click on the item and choose Uninstall
8. Reboot
9. Re-install the original release of the .NET Framework 3.5 (which will re-install the .NET Framework 2.0 SP1 and the .NET Framework 3.0 SP1 behind the scenes)

<update date="8/7/2008"> Added a note clarifying that these uninstall steps are not needed when moving from a beta to the final release.  They are only needed when doing a full uninstall in order to move back to a previous version of the .NET Framework on a system. </update>