Aaron Stebner's WebLog

Visual Studio 2010 and .NET Framework 4 release candidate now available for download

2010-02-09T02:03:12Z

As announced earlier today on Soma’s blog and Jason Zander’s blog, the Visual Studio 2010 and .NET Framework 4 release candidate builds are available for download (today if you are an MSDN subscriber and this Wednesday, February 10, 2010 for the general public). Here are links where you can find additional information and provide feedback to the product teams:

Link to a picture showing what version of the .NET Framework is built into what version of Windows

2010-02-06T00:16:49Z

For a while now, I’ve been maintaining a list of what version of the .NET Framework ships with each version of Windows. The list has gotten longer and more complicated over time as new versions of Windows and the .NET Framework have been released, plus the .NET Framework is off by default in some server versions of Windows.

Today, I noticed that Peter Marcu posted a very handy graphical view of what versions of the .NET Framework starting with 2.0 are a part of what version of Windows, including whether it is optional and on or off by default when you install Windows.

You can check out this graphical view at http://blogs.msdn.com/pmarcu/archive/2010/02/05/which-version-of-net-is-built-into-windows.aspx.

TurboTax 2009 can fail to install because it thinks the .NET Framework is not installed, even when it is

2010-01-27T05:22:00Z

I’ve heard from a few customers over the past few days who have had trouble installing the new 2009 version of TurboTax. In the cases I’ve heard about so far, the installer for TurboTax reports that the .NET Framework 3.5 SP1 is not correctly installed and instructs the user to re-install it. Unfortunately, attempts to uninstall and re-install the .NET Framework did not help in some of these cases.

Behind the scenes, it appears that TurboTax setup is running a verification process that is similar to the .NET Framework setup verification tool. This verification process checks that files and registry keys that should be installed by the .NET Framework 2.0, 3.0 and 3.5 setup packages are correctly installed on the computer. It is possible for the .NET Framework to be installed but for some of the files and/or registry values to have been removed by some other program (such as a registry cleaner tool, a disk cleanup tool, or even manual deletion by the user).

If TurboTax reports a problem with the .NET Framework 3.5, it suggests that you try to uninstall and re-install the .NET Framework 3.5. However, the exact steps needed to do this depend on what version of Windows you are running, and this has ended up causing confusion for the users I’ve heard from so far because the different steps aren’t very well documented in general.

For Windows XP and Windows Server 2003

If you are running a version of Windows before Windows Vista (such as Windows XP or Windows Server 2003), then in most cases, you can use the entry in Add/Remove Programs to repair the .NET Framework 3.5 or 3.5 SP1. If that doesn’t help, then you can use the steps in this blog post to remove and then re-install the .NET Framework 3.5 SP1.

For Windows Vista or Windows Server 2008

If you are running Windows Vista or Windows Server 2008, then the .NET Framework 2.0 and 3.0 are installed as OS components. As a result, the repair steps are more complicated. You will need to try the following:

Try to repair the .NET Framework 3.5 or 3.5 SP1 using the entry in the Programs and Features control panel.
If that doesn’t help, try to use the steps in this blog post to remove and re-install the .NET Framework 3.5 SP1.
If the above steps do not help, run sfc.exe /scannow to attempt to repair the files that are a part of your OS (which will also repair some parts of the .NET Framework).

For Windows 7

If you are running Windows 7, then the .NET Framework 2.0, 3.0 and 3.5 are all installed as OS components, and you cannot remove or re-install these versions using the Programs and Features control panel. On Windows 7, this is your only built-in repair option:

Run sfc.exe /scannow to attempt to repair the files that are a part of your OS (which will also repair some parts of the .NET Framework).

What to do if the above doesn’t help

Unfortunately, sfc.exe will only repair files that are protected by Windows Resource Protection. For the .NET Framework, only binary files that can be repaired using sfc.exe. Non-binary files (such as .config files) and registry keys cannot be repaired using sfc.exe. For non-binary files, the only options are to manually replace them with files from other computers or to repair your OS. For registry keys, the only options are to manually re-create them in regedit.exe or to repair your OS.

Here are some steps I’ve been able to use to narrow down the exact missing files and/or registry keys that cause TurboTax setup to think that the .NET Framework 3.5 SP1 is not correctly installed:

Download and run the TurboTax verification utility from http://turbotax.intuit.com/support/kb/installing/errors/7659.html
When the utility finishes, click the button named Save Logs on Desktop
Go to your desktop and open the zip file named TurboTax2009UtilityLogFiles*.zip
Find the file named *_TurboTax 2009 Utility – *.log (where the first * is a date-time stamp and the 2nd * is a version number)
Search for the string ****ERROR**** in this log file and take note of the files and/or registry keys that it reports are missing

From the information in this log file, it is usually possible to figure out what files and/or registry keys need to be manually repaired on the computer. So far, the cases I’ve seen reported missing .config files and we have been able to get TurboTax setup to run correctly after copying the .config files from another computer or downloading them from here and putting them in the locations reported in this log file.

If you run into problems getting TurboTax 2009 setup to run correctly due to errors related to the .NET Framework 3.5, I encourage you to try the steps above. If they don’t help, please don’t hesitate to leave a comment on my blog and/or contact me and I’ll try to help as best as I can.

<update date="2/3/2010"> Added a link to a zip file that I posted with the .config files that have been causing the majority of the issues with TurboTax setup that I've seen so far. </update>

A simpler way to add Windows Installer major upgrade functionality to your MSI in WiX v3.5

2010-01-19T21:33:08Z

Bob Arnson has been working on some simplifications to the WiX language in WiX v3.5, and he has posted some introductory information about a couple of these changes on his blog. I wanted to link to them here to hopefully help raise visibility for these simplifications:

I have found the major upgrade simplifications to be particularly useful. A while back, I wrote a step-by-step guide for authoring, building and testing major upgrades using WiX, and that guide later got added to the WiX documentation.

As you can see in Bob’s blog post and in the WiX MajorUpgrade element documentation, Bob’s simplifications will allow WiX v3.5 to handle creating the Upgrade table elements, scheduling the RemoveExistingProducts action, and optionally blocking downgrades if a user tries to install an older version of the MSI after installing a newer version. You only need to make sure that you include UpgradeCode and Version attributes in your Product element, and then you can use the new MajorUpgrade element in your WiX v3.5 authoring.

If you choose to, you can continue to use the more verbose syntax described in my previous blog post or the WiX documentation for authoring a major upgrade, but you could instead convert to the new MajorUpgrade element in order to more clearly express the behavior you intend for your MSI and to simplify your setup authoring.

The major upgrade and component authoring functionality described in the above blog posts is available in WiX v3.5 builds starting with the v3.5.1315.0 build on SourceForge, and I encourage you to check them out.

Possible issue where machine.config can be overwritten by .NET Framework 2.0 SP2 setup

2009-12-21T20:07:00Z

Description of the issue

I heard from someone recently who noticed that some information was removed from the file machine.config after installing the .NET Framework 2.0 SP2. Their scenario looked like the following:

Install Windows XP or Windows Server 2003
Install the .NET Framework 3.5 (which installs 2.0 SP1 and 3.0 SP1 behind the scenes, and which adds some information about 3.5 assemblies to the 2.0 machine.config)
Install the .NET Framework 2.0 SP2
Look at the contents of machine.config (located at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config on an x86 OS or C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\CONFIG\machine.config on an x64 OS)

In the above scenario, the entries added to machine.config during .NET Framework 3.5 installation in step 2 were removed from machine.config during .NET Framework 2.0 SP2 installation in step 3.

How to work around this issue

If you run into a scenario where machine.config is incorrectly overwritten when installing the .NET Framework 2.0 SP2, you can work around it in one of the following ways:

If you have not yet installed the .NET Framework 2.0 SP2, you can manually back up your copy of machine.config, then copy it back after installing the .NET Framework 2.0 SP2.
If you have already installed the .NET Framework 2.0 SP2, you can repair/re-install other products that updated machine.config (such as the .NET Framework 3.5), or you can manually re-add the information to machine.config that was removed by the .NET Framework 2.0 SP2 installation process.
Instead of installing the standalone .NET Framework 2.0 SP2 package, you could instead install the .NET Framework 3.5 SP1 package (which will also install the .NET Framework 2.0 SP2 and 3.0 SP2 for you behind the scenes). The .NET Framework 3.5 SP1 installation process will add the necessary information to machine.config that may otherwise be missing in this scenario.

What can cause this issue

.NET Framework 2.0 SP2 setup follows the standard Windows Installer file replacement logic for unversioned files, which causes it to not replace machine.config if that file was updated by some other program after it was originally installed. However, we have seen some cases where the last modified time stamp does not get updated during .NET Framework 3.5 setup. If this happens, then the installation of the .NET Framework 2.0 SP2 does not correctly recognize that some other program has updated machine.config, and as a result, the .NET Framework 2.0 SP2 installation process overwrites machine.config with a default copy that is included with the .NET Framework 2.0 SP2 installer.

One note – so far, we have only seen this issue affect computers that have an MSI-based version of the .NET Framework 2.0 installed (Windows XP, Windows Server 2003). The issue does not appear to affect versions of Windows that include the .NET Framework 2.0 as an OS component (Windows Vista, Windows Server 2008, Windows 7).

<update date="12/29/2009"> Added another possible workaround for this issue - install the .NET Framework 3.5 SP1 package instead of just installing the .NET Framework 2.0 SP2 package. </update>

Fix for possible NGen service deadlocks during product installation is coming in the .NET Framework 4

2009-12-05T01:16:36Z

A while back, I wrote a blog post about a scenario that can lead to deadlocks when using synchronous native image generation (NGen) actions in a setup program. I recently heard from Surupa Biswas (the program manager on the NGen team at Microsoft who originally informed me of this issue), and she let me know that her team has implemented a fix in the NGen service that will solve this problem in the upcoming release of the .NET Framework 4. The fix is not available in the .NET Framework 4 beta 2, but will be available in the final release early in 2010. Here is more information about the issue, the fix, and the implications for setup programs that use NGen.

Introduction

In previous versions of the .NET Framework, any setup that includes NGen actions for optional components can potentially cause deadlocks because the NGen service may invoke the installation and native image generation for an optional component, and the NGen service is not fully re-entrant. In the upcoming release of the .NET Framework 4, the NGen team has addressed this potential deadlock by modifying NGen so that it never invokes the installation and native image generation for an optional component.

What will happen at NGen time

When NGen attempts to generate a native image for A.dll, and A.dll has a static dependency on some optional component B.dll that is not yet installed, NGen will generate a partial native image for A.dll (whereas the previous version of NGen would have attempted to install and generate a native image for B.dll, which led to potential deadlocks). This partial native image contains all the native code and data structures that can be generated without using information from B.dll. For example, if a type in A.dll inherits from a type in B.dll or contains some fields of types defined in B.dll, then this type will not be included in the partial native image.

What will happen at execution time

When the user runs a managed application that uses A.dll, the CLR will load the partial native image for it. Any native code and data structures that are included in the native image can be used by CLR in the normal way. If the application tries to use a type or method that is missing from the partial native image, the CLR will notice the missing information, and it will try to generate the data structures or JIT compile the missing methods. Since B.dll is needed to generate the data structures, the CLR will ask the setup program for A.dll and B.dll to install the optional component B.dll. After B.dll is installed, the application can continue running. It is safe for the setup program for A.dll and B.dll to issue both synchronous and asynchronous NGen commands in this case.

What setup should do

Installing B.dll will invalidate the partial native image for A.dll. The partial native image can still be used by any applications that are already running at the time when B.dll is installed, but all applications started later will need a new (complete) native image of A.dll. The setup program should therefore request that NGen recompile A.dll when it installs B.dll. To trigger this recompilation, the NGen team recommend that the setup program issue the command ngen.exe update /queue command at the end of the installation process. This will ensure that all native images that depend on B.dll are updated.

Mailbag: Why does Windows Update continue offering the .NET Framework 3.5 SP1 after I install it?

2009-11-24T21:57:53Z

Question:

I recently installed the .NET Framework 3.5 SP1 on my computer. Afterwards, I went to the Windows Update site to check for updates, and I see the following item in the list of updates that my computer needs:

Microsoft .NET Framework 3.5 Service Pack 1 and .NET Framework 3.5 Family Update for .NET versions 2.0 through 3.5 (KB951847)

Does this mean that the .NET Framework 3.5 SP1 failed to install correctly when I installed it previously? What do I do to fix this issue?

Answer:

No, this does not mean that the .NET Framework 3.5 SP1 failed to install correctly on your system. Unfortunately, the wording of the name of this update in Windows Update is confusing. The .NET Framework 3.5 Family Update is an additional hotfix package that needs to be installed after installing the .NET Framework 3.5 SP1. Windows Update automatically bundles the .NET Framework 3.5 SP1 with the .NET Framework 3.5 Family Update if it detects that the .NET Framework 3.5 SP1 is not yet installed on your computer. However, if the .NET Framework 3.5 SP1 is already installed on your computer, Windows Update will only install the .NET Framework 3.5 Family Update even though the name of the item includes “Microsoft .NET Framework 3.5 Service Pack 1” in it.

If your computer is in this state, you should be able to simply allow Windows Update to install the .NET Framework 3.5 Family Update on your system.

Additional troubleshooting steps in case the .NET Framework 3.5 Family Update fails to install

Note that if the .NET Framework 3.5 Family Update fails to install, there should be log files created on your computer to help narrow down the cause of the failure further. They will be located in a sub-directory of your %temp% directory and have a folder name that includes the KB number of the .NET Framework 3.5 Family Update. There are several possible KB numbers for the .NET Framework 3.5 Family Update:

KB958481
KB958483
KB958484

WiX v3.5 now includes support for Visual Studio 2010 beta 2

2009-11-17T02:41:20Z

As previously posted on Rob Mensching’s blog and Bob Arnson’s blog, builds of WiX v3.5 starting with the 3.5.1030.0 build include support for Visual Studio 2010 beta 2. Here are some highlights:

Extension Manager integration – you can download and install WiX v3.5 directly from within the VS 2010 IDE; to do this, launch VS 2010 Professional Edition or higher, click on the Tools menu, choose Extension Manager...., select the Online Gallery on the left side of the Extension Manager UI, expand Tools, then Build, and you’ll see the Windows Installer XML Toolset listed there.
WiX can now run on the .NET Framework 4 and it can process .NET Framework 4 assemblies during builds.
Major performance improvement when building WiX projects in the VS IDE – you will no longer see the VS IDE appear to hang during builds.
Automatic upgrade of .wixproj files from the VS 2008 file format to the VS 2010 file format.
Improvements in the VS IDE experience for WiX projects – drag/drop of nodes, copy/paste of items, project references.
Visual Studio 2010 Express Edition detection properties and custom actions have been added to the WixVSExtension.
Numerous other miscellaneous bug fixes.

If you encounter any bugs with these new features or have suggestions for improvements, please report them on the WiX bug reporting site or the WiX feature request site. If you have any questions about using these new features or about WiX in general, I encourage you to use the WiX mailing lists.

Suggestions for resolving installation errors for .NET Framework security update MS09-061

2009-10-23T20:01:37Z

I have heard from several people over the past week or so who have had problems getting the recently released .NET Framework security update (MS09-061) to install correctly on their system when it is offered to them by Windows Update or Microsoft Update. This blog post will describe what this type of failure typically looks like and will offer some steps you can use to try to resolve this type of error.

For reference, this .NET Framework security update is listed on the Windows Update download page with several different possible knowledge base numbers, depending on what version of the .NET Framework the update applies to and what operating system you are running. Here is a list of knowledge base article numbers for this security update:

For the .NET Framework 2.0 on operating systems before Windows Vista - KB953300 and KB974417
For the .NET Framework 2.0 on Windows Vista and Windows Server 2008 - KB974468, KB974292, KB974467, KB974291, KB974469 and KB974470
For the .NET Framework 1.1 - KB953297
For the .NET Framework 1.0 - KB953295

Description of the issue

If this .NET Framework security update or any other update fails to install when running it from the Windows Update site, you will normally see Windows Update report back a generic error code of 0x643 or 1603. This is a catch-all error code that means that setup failed, but it doesn’t provide any more detailed information about why it failed or how to fix the failure.

In most cases, when a .NET Framework update fails to install with a 0x643 or 1603 error code, it means that there is something wrong with the version of the .NET Framework that is installed on the system that the update is supposed to be fixing. There are a few different ways to go about resolving this error and getting the update to install successfully.

How to solve the issue by uninstalling and re-installing the .NET Framework

The simplest way to solve this type of issue is to use the steps listed at http://blogs.msdn.com/astebner/archive/2008/03/07/8108332.aspx to remove all versions of the .NET Framework from your system, then re-install them in the following order:

.NET Framework 3.5 SP1 (this version of the .NET Framework will also install the .NET Framework 2.0 SP2 and the .NET Framework 3.0 SP2 for you behind the scenes, so you don’t need to re-install 2.0 or 3.0 using separate steps)
.NET Framework 1.1
.NET Framework 1.1 SP1

After this, you should be able to go back to the Windows Update site, scan for updates again and install the latest updates for the .NET Framework 1.1 and 2.0 from there.

Note – after removing all versions of the .NET Framework, you do not necessarily have to re-install the .NET Framework 1.0 or 1.1 if you do not have any applications that are using them. Most .NET applications will automatically use the latest version of the .NET Framework that is installed on your system, and those that do not will give an error message indicating that you need to install a different version. There is more information about this scenario in this blog post if you are interested in reading further.

How to solve the issue by finding more information about the root cause

The above steps involve uninstalling, re-downloading and re-installing all of the versions of the .NET Framework on your system, which can be a bit time consuming. Instead, if you prefer, you can try to narrow down the root cause of the .NET Framework security update installation error further and try to solve this issue without performing all of the .NET Framework uninstalls and re-installs listed above.

There are a couple of things I usually do to try to narrow down the root cause of this type of .NET Framework security update installation failure further:

Try to download and install the update yourself instead of letting Windows Update install it for you.

Windows Update always runs the installers for updates in silent mode, which can hide some useful error messages if the updates fail. You can find the links to download this .NET Framework security update by going to the page for the security bulletin, scrolling down to the Affected Software table, and locating the link in the Component column of the table that corresponds to the version of the .NET Framework you need to update and the operating system you are running.
Look at the setup log files created by the security update.

This .NET Framework security update should create log files in a sub-directory under your %temp% directory. The sub-directory will have the knowledge base article number in the name. For example, the .NET Framework 1.1 security update (KB953297) will create logs in a folder named %temp%\NDP1.1sp1-KB953297-X86.

Link to information about .NET Framework 4 setup and deployment improvements

2009-10-23T00:34:52Z

Peter Marcu has posted some detailed information about improvements that have been made to the setup and deployment process for the .NET Framework 4 starting with the recently released .NET Framework 4 beta 2 and Visual Studio 2010 beta 2. The improvements have been made to solve issues that exist in the .NET Framework 3.5 and 3.5 SP1 and to address customer feedback that has been received from previous releases. The improvements that Peter describes are focused on the following areas:

Size – making the overall download and install size of the .NET Framework 4 smaller
Robustness – making the download and installation process more reliable
Performance – making the download and install time faster

I encourage you to read Peter’s blog post at http://blogs.msdn.com/pmarcu/archive/2009/09/30/net-framework-4-0-beta-2-deployment.aspx to learn more about the specific improvements being made to the .NET Framework setup and deployment process in the .NET Framework 4 product.

Important uninstall instructions for migrating from the .NET Framework 4 and VS 2010 beta 1 to beta 2

2009-10-19T22:29:00Z

As noted on Soma’s blog, the .NET Framework 4 beta 2 and Visual Studio 2010 beta 2 have been released today. If you previously had the .NET Framework 4 beta 1 and/or Visual Studio 2010 beta 1 installed, there are some very important uninstall instructions that you must follow in order to fully uninstall beta 1 so that beta 2 will work correctly.

If you had the .NET Framework 4 beta 1 and/or VS 2010 beta 1 installed, please follow the instructions at http://go.microsoft.com/fwlink/?LinkID=167718 to fully uninstall beta 1 before you install beta 2.

These instructions explain how to fully uninstall VS 2010 beta 1 and then fully uninstall the .NET Framework 4 beta 1. If you do not follow the above instructions, you may see a crash dialog during the installation of VS 2010 beta 2, and you may see package load failures when trying to use VS 2010 beta 2. The instructions linked above also contain steps to repair the .NET Framework 4 beta 2 and VS 2010 beta 2 in order to recover from these errors.

If you run into any issues that are not covered by the above instructions, I encourage you to check out the .NET Framework 4 and VS 2010 pre-release forums for additional troubleshooting suggestions and workarounds.

Diagnosing and resolving 1935 errors for Win32 assemblies that occur on Windows Vista and later

2009-10-07T17:24:00Z

Introduction

1935 errors can occur during an MSI-based installation while installing .NET assemblies or Win32 assemblies. Most of the workarounds that can be found on blogs and forums (including all of the information in my 1935 error troubleshooting guide) only apply to 1935 errors that happen while installing .NET assemblies.

This blog post will explain how to troubleshoot 1935 errors that occur while attempting to install Win32 assemblies in an MSI-based installer.

The information in this blog post only applies to Windows Vista and later versions of Windows, and it also only applies to Win32 assemblies.

For additional information about troubleshooting 1935 errors that occur on versions of Windows before Windows Vista and that occur for managed (.NET Framework) assemblies, please refer to the 1935 error troubleshooting guide.

How to identify a 1935 error caused by a Win32 assembly on Windows Vista and later

For 1935 errors that occur while installing Win32 assemblies in an MSI-based setup (which I have seen most commonly in the past for Visual C++ runtime files), there are some specific diagnosis and troubleshooting steps that you will need to use that are different than the ones used for managed assemblies.

On Windows Vista and higher, Windows Installer uses the same underlying installation engine as the OS component installation engine (also known as CBS) to install Win32 assemblies. As a result, anything that can cause an OS update or hotfix to fail to install can cause this type of 1935 error. You will typically need to do some more in-depth analysis on the affected system in order to narrow down the root cause and identify possible solutions.

When this type of 1935 error occurs, you will see the following information in a verbose MSI log file:

MSI (s) (54:32) [12:34:56:789]: Assembly Error (sxs): To get more diagnostic information, enable the Component Based Servicing Log.

How to identify a root cause and possible solution

As the above log file entry suggests, there is not enough detailed error information in a verbose MSI log file to determine a root cause of this type of 1935 error. That means you will need to look in the Component Based Servicing (CBS) log file to try to narrow down the root cause further. This log file is enabled and created by default on Windows Vista and higher, and it is located at %windir%\logs\cbs\cbs.log.

You will notice that cbs.log is typically very large and can be difficult to read. What I typically do is look at the time stamps for the 1935 error messages in the verbose MSI log file, then cross-reference those time stamps with the ones listed in cbs.log to try to find the exact error in cbs.log. From there, I use the links listed in the blog post at http://blogs.msdn.com/astebner/archive/2009/03/12/9472695.aspx to find more detailed information about the error code that is listed in cbs.log and to try to come up with workarounds from there.

In some cases, the operating system will lock the file cbs.log so that you cannot open it. In those cases, it usually works to make a copy of cbs.log in a new location and then open the copy of the file instead.

Unfortunately, a 1935 error caused by a Win32 assembly on Windows Vista and later can be a pain to diagnose and solve because of the wide range of possible causes. I have had the most luck in the past by using the System Update Readiness Tool to solve issues related to the OS component installation engine. There are some steps listed at http://blogs.msdn.com/astebner/archive/2009/01/09/9303167.aspx that I recommend trying in a lot of these scenarios.

Note - If you see error code 0x800705aa (which means ERROR_NO_SYSTEM_RESOURCES) in your cbs.log file, then it could be caused by the issue described in this discussion thread.

<update date="1/18/2010"> Added a link to a discussion of error code 0x800705aa in cbs.log. </update>

Mailbag: How to manage reboots when installing multiple versions of the .NET Framework

2009-09-29T03:59:10Z

Question:

I am planning a network deployment of the .NET Framework, and I need to deploy all versions from 1.0 through 3.5 SP1 if any are missing on each of the computers on the network. I have 2 questions related to reboots:

Is it possible to install all versions of the .NET Framework without any reboot being required?
If it is not possible, can I ignore all reboot prompts and only reboot once after installing all versions of the .NET Framework?

Answer:

It is not possible to guarantee with 100% accuracy whether or not a reboot will be needed before running .NET Framework setup. Reboots during .NET Framework setup are caused by files being in use that need to be updated during the installation process. Whether or not a reboot will be needed depends on the state of the computer that .NET Framework setup is being run on. If there are any .NET Framework applications or services running on the computer, then they can lead to reboots being needed during installation of the .NET Framework.

When deploying the .NET Framework, you should install in silent or unattended mode and rely on the exit codes from the installation processes to determine whether or not a reboot is needed. All .NET Framework setup packages will return the following exit codes:

0 – installation is successful and no reboot is needed
3010 – installation is successful and a reboot is needed
Any other value – installation failed

If you receive a 3010 exit code from a .NET Framework installation process, you can safely defer the reboot until after you install all versions of the .NET Framework. However, you must schedule a reboot at the end of the overall installation process if you receive a 3010 exit code from any of the .NET Framework installation processes. You cannot safely defer a requested reboot if you also plan to install or run a .NET Framework application on the computer. All .NET Framework applications require that the .NET Framework be fully installed before they will be able to run reliably, including completing any reboots that are requested.

If you plan to install all versions of the .NET Framework on a computer, you can minimize the number of reboot requests that you might get by doing the following:

If possible, close any .NET Framework applications and stop any .NET Framework services that are running on the computer before running any .NET Framework setup.
Create an administrative install point for the .NET Framework 1.1 + the latest service packs and updates if desired.
Create an administrative install point for the .NET Framework 1.0 + the latest service packs and updates if desired.
Install the .NET Framework 4 if desired.
Install the .NET Framework 3.5 SP1 (which will install the .NET Framework 2.0 SP2 and 3.0 SP2 behind the scenes).
Install the .NET Framework 1.1 + the latest SP from the install point created in step 2.
Install the .NET Framework 1.0 + the latest SP from the install point created in step 3.

Installing the versions of the .NET Framework from newest to oldest will help ensure that the highest versions of any shared files are installed first. That way, even if the files end up in use during the later installation processes, the .NET Framework setup program will not need to replace them because a higher version will already be installed.

There are example steps for creating the administrative install points described in steps 2 and 3 above in the blog post at http://blogs.msdn.com/astebner/archive/2005/03/05/385971.aspx.

XNA Game Studio 3.1 Zune Extensions now available for download

2009-09-15T22:21:45Z

The XNA Game Studio 3.1 Zune Extensions was posted on the Microsoft Download Center today. This product can be installed on a system that has XNA Game Studio 3.1 installed, and it adds the following functionality to the XNA Game Studio 3.1 product:

The ability to develop and deploy games to the new Zune HD media player using XNA Game Studio 3.1.
New touch APIs to the XNA Framework for use on the Zune HD.
New accelerometer APIs to the XNA Framework for use on the Zune HD.
New documentation and samples that demonstrate how to use the new touch and accelerometer APIs.
A new tutorial demonstrating how to add support for the new touch APIs to the Platformer starter kit that ships with XNA Game Studio 3.1.

Here are a couple of links to help you get started installing and using the XNA Game Studio 3.1 Zune Extensions:

Download location - http://www.microsoft.com/downloads/details.aspx?FamilyID=48f7ba37-8ba7-4d16-8873-0b7f83ef77f9
Creators Club forum post - http://forums.xna.com/forums/p/38975/226669.aspx

Possible workarounds for project type is not supported by this installation error in XNA Game Studio

2009-08-31T02:04:00Z

Note - my colleague Yuichi Ito has provided a Japanese version of the information in this blog post. You can find it at this location on his blog.

Every so often, I hear from a user who has encountered an error like the following while trying to open an XNA Game Studio project in Visual Studio:

The project type is not supported by this installation.

There are a couple of common causes that I’ve seen for this type of error, so I wanted to describe each of them here in case they help anyone who encounters this type of error in the future.

Issue 1: The project file is from a version of XNA Game Studio not installed on the system

If you have an XNA Game Studio project created with a different version than you have installed on your system (for example, if you download a sample from the Creators Club site or something like that), then you might encounter this error.

There are automatic upgrade paths for some versions of XNA Game Studio, but not for all of them. An XNA Game Studio Express 1.0 or 1.0 Refresh game can be opened with XNA Game Studio 2.0. An XNA Game Studio 2.0 project can be opened with XNA Game Studio 3.0 or 3.1. An XNA Game Studio 3.0 project can be opened with XNA Game Studio 3.1. Other combinations may lead to this error message.

For example, you cannot open a project created with XNA Game Studio 3.0 on a system that only has XNA Game Studio 2.0 installed or has Visual Studio 2008 but does not have XNA Game Studio 3.0 installed.

If this is the issue causing the error on your system, you will need to make sure that you have the version of XNA Game Studio installed that the project was created with, or you can create a new project using the version of XNA Game Studio that you have installed and then import the code and content from the original project as a workaround.

Issue 2: The XNA Game Studio package is not loading properly

In some cases, XNA Game Studio is installed, but there is some kind of problem that causes it to fail to load correctly in Visual Studio. I have seen this happen in the past (for example, in this forum post) when a user encountered a package load failure dialog like the following, and then clicked on the Yes button. Doing this will prevent Visual Studio from loading the XNA Game Studio package in the future (which is why I personally always make sure to click No if I ever encounter a package load failure dialog within Visual Studio):

If this is the cause of the error message on your system, you can run one of the following command lines to reset Visual Studio so that it will not automatically skip loading the XNA Game Studio package the next time you run Visual Studio:

For Visual Studio 2005 Standard Edition and higher: %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\devenv.exe /ResetSkipPkgs
For Visual C# 2005 Express Edition: %ProgramFiles%\Microsoft Visual Studio 8\Common7\IDE\vcsexpress.exe /ResetSkipPkgs
For Visual Studio 2008 Standard Edition and higher: %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe /ResetSkipPkgs
For Visual C# 2008 Express Edition: %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\vcsexpress.exe /ResetSkipPkgs

Note – the above command lines assume that you have installed Visual Studio to the default location. You may need to modify the command lines depending on where Visual Studio is installed on your system.

<update date="11/16/2009"> Added a link to a Japanese version of the information in this blog post. Thanks Ito! <update>