Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS with no warranties, and confer no rights. Additionally, views expressed herein are my own and not those of my employer, Microsoft.
As noted in the Highlights of WiX v3.0.4311.0 post on Bob Arnson's blog, Neil Enns recently contributed several how-to topics to the WiX v3.0 documentation. One of these how-to topics describes how to include DirectX 9.0c runtime files in an MSI-based installer by authoring the DirectX setup files into the MSI and then creating a custom action to run dxsetup.exe. These steps are particularly useful for developers creating MSI-based installers for XNA Framework-based games. Since the WiX documentation is not currently available in HTML format on the Internet, I decided to re-print this how-to topic here in order to help developers more easily find this information and utilize it in their installers if it makes sense.
I had to make a couple of small modifications to the topic that is in the WiX documentation because the topic includes links to other documentation topics, but the rest is a verbatim reprint of the documentation topic written by Neil. This how-to requires some basic WiX authoring knowledge in order to fully comprehend and use. If anyone tries out these steps and runs into any issues, please feel free to leave a comment at the end of this post or contact me and I can try to help get you unblocked.
Also, as a side note - the steps listed below are essentially the same way that XNA Game Studio setup (which uses WiX v3.0 as described here) installs the parts of the DirectX 9.0c runtime files that are needed for XNA Framework-based games.
Applications that require components from DirectX 9.0 can benefit from including the DirectX 9.0 Redistributable inside their installer. This simplifies the installation process for end users and ensures the required components for your application are always available on the target user's machine.
DirectX 9.0 can be re-distributed in several different ways, each of which is outlined in MSDN's Installing DirectX with DirectSetup article. This how to describes using the dxsetup.exe application to install DirectX 9.0 on a Vista machine assuming the application being installed only depends on a specific DirectX component.
Prior to redistributing the DirectX binaries you should read and understand the license agreement for the redistributable files. The license agreement can be found in the Documentation\License Agreements\DirectX Redist.txt file in your DirectX SDK installation.
Adding the files to the WiX project follows the same process as described in the topic How To: Add a file to your installer in wix.chm. The following example illustrates a typical fragment that includes the necessary files:
<
The files included are the minimal set of files required by the DirectX 9.0 install process, as described in the MSDN documentation. The last file in the list, DEC2006_d3dx9_32_x86.cab contains the specific DirectX component required by the installed application. These files are all included in a single component as, even in a patching situation, all the files must go together. A Feature element is used to create a feature specific to DirectX installation, and its Display attribute is set to hidden to prevent the user from seeing the feature in any UI that may be part of your installer.
To run the DirectX 9.0 installer a custom action is added that runs before the install is finalized. The <CustomAction>, <InstallExecuteSequence> and <Custom> elements are used to create the custom action, as illustrated in the following sample.
The CustomAction element creates the custom action that runs the setup. It is given a unique id, and the FileKey attribute is used to reference the installer application from Step 1. The ExeCommand attribute adds the /silent flag to the installer to ensure the user is not presented with any DirectX installer user interface. The Execute attribute is set to deferred and the Impersonate attribute is set to no to ensure the custom action will run elevated, if necessary. The Return attribute is set to check to ensure the custom action runs synchronously.
The Custom element is used inside an InstallExecuteSequence to add the custom action to the actual installation process. The Action attribute references the CustomAction by its unique id. The Before attribute is set to InstallFinalize to run the custom action before the overall installation is complete. The condition prevents the DirectX installer from running when the user uninstalls your application, since DirectX components cannot be uninstalled.
If you are using standard WiX UI dialogs you can include custom progress text for display while the DirectX installation takes place. The <UI> and <ProgressText> elements are used, as illustrated in the following example.
The ProgressText element uses the Action attribute to reference the custom action by its unique id. The value of the ProgressText element is set to the display text for the install progress.
Note: When you build an MSI using the above steps, you will see ICE03 warnings reported for a couple of the DirectX 9.0c setup files. The warnings will look like the following:
warning LGHT1076 : ICE03: String overflow (greater than length permitted in column); Table: File, Column: Language, Key(s): DXSETUP.exewarning LGHT1076 : ICE03: String overflow (greater than length permitted in column); Table: File, Column: Language, Key(s): dsetup32.dll
These warnings are caused by the language metadata for these files being too long for one of the column definitions in Windows Installer. These warnings will not cause any installation problems for the MSI that you create, so you can safely ignore these warnings.
<update date="11/26/2008"> Added a note about ICE03 warnings that will occur when building an MSI using the steps in this blog post. </update>
I have heard from several customers in the past who have had issues installing hotfixes or updates for Windows Vista or Windows Server 2008. This type of problem can happen during .NET Framework 3.5 setup and .NET Framework 3.5 SP1 setup because these products install service packs for the .NET Framework 2.0 and 3.0 behind the scenes, and those service packs are OS updates on Windows Vista and Windows Server 2008 because the .NET Framework 2.0 and 3.0 are installed as OS components on those OS's.
In the past, when customers have contacted me with Windows Vista OS and Windows Server 2008 update installation errors, the options I have been able to give them to help resolve the errors were pretty limited - I typically suggested trying to run the SFC tool and/or suggested upgrading to Windows Vista SP1. I just noticed a knowledge base article that has been posted for a little while that provides a tool that can help solve Windows Vista and Windows Server 2008 OS update installation problems and I wanted to link to it here to help people find it in the future.
Information about the tool
The tool is called the System Update Readiness Tool, and the Windows Vista version of this tool is described in more detail in the knowledge base article at http://support.microsoft.com/kb/947821.
This tool will scan your Windows Vista or Windows Server 2008 system to search for inconsistencies in the files and registry information related to installed OS components and OS updates that can lead to future OS updates failing to install correctly. If any are found, it tries to resolve them to put your system back into a known state. The knowledge base article lists the exact files and registry locations that the tool will scan and attempt to repair. It also lists some of the return codes that can be reported by OS updates that the tool can typically fix for you.
Where to download the tool
Here are download locations for the System Update Readiness Tool for Windows Vista:
How to tell if the tool will help if you encounter .NET Framework 2.0 SP or 3.0 SP install failures on Windows Vista or Windows Server 2008
The System Update Readiness Tool might help in the following .NET Framework installation scenarios:
If you are encountering a problem with one of the above installation scenarios, it could be caused by a failure to install one of the .NET Framework 2.0 or 3.0 OS update packages. The exact setup return codes will be listed in the setup log file named %temp%\dd_dotnetfx35install*.txt (from the list in this blog post). You can search for the exact return code from .NET Framework 2.0 SP1 or SP2 setup by looking for a line like the following (where #### is the actual numerical return code on your system):
[05/01/08,09:09:09] Microsoft .NET Framework 2.0SP1 (CBS): C:\Windows\system32\WUSA.exe exited with return value ####.
You can search for the exact return code from .NET Framework 3.0 SP1 or SP2 setup by looking for a line like the following (where #### is the actual numerical return code on your system):
[05/01/08,09:09:09] Microsoft .NET Framework 3.0SP1 (CBS): C:\Windows\system32\WUSA.exe exited with return value ####.
<update date="8/19/2008"> Added links for the Windows Server 2008 version of the System Update Readiness Tool because it can be useful when trying to troubleshoot .NET Framework 3.5 SP1 install issues on Windows Server 2008. </update>
<update date="8/26/2008"> Added link to the Windows Server 2008 ia64 version of the System Update Readiness Tool. </update>
<update date="1/7/2009"> Fixed broken links to some versions of the System Update Readiness tool. </update>
Three new community spotlight features were posted today on the XNA Creators Club Web site, and I want to link to them here and encourage you to take a look. Here is a bit more information about each of them:
You can find a full collection of XNA Creators Club community spotlight features on this page.
Recently, I noticed this post on the Big Screen Blog where Niall Ginsbourg talks about some changes he made to the installers for his Big Screen applications for Windows Vista Media Center. He didn't go into much detail about what he changed, so I want to explain the OS version detection that happens in the WiX v3.0-based installer files included with the Windows Media Center application project templates that ship in the Windows Media Center SDK v5.3 and that I have previously posted on my blog (for example, here and here). I will also outline the types of changes you may want to make in the OS version conditions in your Windows Media Center application installers depending on what scenarios you plan to support in the future.
For the WiX syntax quoted in this blog post, I will refer to the WiX v3.0 setup files that are created by the Visual Studio project templates that ship in the Windows Media Center SDK. You can find these setup files in the Setup sub-folder after creating an instance of one of the Windows Media Center project templates after installing Visual Studio and the Windows Media Center SDK v5.3.
Description of the OS install block in existing Media Center application setup samples
The WiX source file in the Windows Media Center project templates (named Setup.wxs) includes a custom action to block installation if the user attempts to run the MSI on an unsupported OS. The custom action is defined by the following WiX element:
<CustomAction Id="CA_ErrWrongWindowsVersion" Error="!(loc.LaunchCondition_WrongOSVersion)" />
Later on in Setup.wxs, the conditions are defined that control when this custom action will be run. The following WiX element is included in both the InstallExecuteSequence table and the InstallUiSequence table in order to make sure that the custom action will run if the MSI is installed in full UI mode or in silent mode:
<Custom Action="CA_ErrWrongWindowsVersion" Before="CostInitialize"><![CDATA[(NOT VersionNT = 600 OR NOT MCEINSTALLVERSION = "5.0" OR NOT REGISTERMCEAPP) AND NOT Installed]]></Custom>
There are 4 specific conditions that are checked for this custom action:
Of the conditions listed above, the VersionNT condition (item 1) and the MCEINSTALLVERSION condition (item 2) are not future-proof. In other words, they will end up causing setup to block on future versions of Windows and Windows Media Center if they end up being configured to use higher values for the VersionNT property and/or the Ident registry value.
When we shipped these example installers in the Media Center SDK, we made a conscious decision to bind the installers to a specific, known version of Windows and Windows Media Center. This is because the known version is the only one that can currently be tested and assured of working correctly with Media Center application code developed using the SDK.
Making the install conditions less restrictive
In your scenario (and in the scenario Niall described in his blog post), you may find these conditions too restrictive and may want to update your Media Center application installer so that you do not necessarily have to release new versions of your installers if new versions of Windows and/or Windows Media Center ship with higher values for the VersionNT property and/or the Ident registry value in the future.
If you would like to loosen the restrictions in your installer, I suggest changing the custom action condition to the following:
<Custom Action="CA_ErrWrongWindowsVersion" Before="CostInitialize"><![CDATA[(NOT VersionNT >= 600 OR NOT MCEINSTALLVERSION OR NOT REGISTERMCEAPP) AND NOT Installed]]></Custom>
This condition contains the following changes when compared to the original Setup.wxs file that is created by the project templates in the Windows Media Center SDK:
Note that you must make sure to change this condition in both the InstallExecuteSequence table and the InstallUiSequence table in your WXS file or else you will see different install blocking behavior in full UI mode versus silent mode.
A real-world example - PowerPlaylist
You can take a look at the WiX source code for the PowerPlaylist application on Codeplex for an example of less restrictive installation conditions. The installer for PowerPlaylist was initially created from a Windows Media Center project template in the SDK, and it was later modified to contain less restrictive OS installation conditions. PowerPlaylist is used within the Media Center team at Microsoft as an application compatibility test case, so it had to be modified to allow installation on any possible version of Windows Media Center starting with Windows Vista. There are trade-offs related to application compatibilty that you have to make if you decide to make the OS installation conditions in your Media Center application installer less restrictive though - see the note at the end of this blog post for more details.
Note that unlike the recommendation above, the installer for PowerPlaylist does not check for the Ident registry value at all (you will not see any reference to the MCEINSTALLVERSION property in that installer). This option will also work, but I recommend checking that the Ident value exists is an extra safeguard to make sure that the system really does contain Windows Media Center. A system should not be able to contain Windows Media Center functionality without the Ident registry value also being present.
A word of caution about less restrictive installation conditions
If you decide to update the installer for your Media Center application to include less restrictive OS install conditions, please note that this will allow your application to install on any possible future version of Windows and/or Windows Media Center. Since these future versions do not yet exist, it is impossible to know whether or not your application will continue to be compatible with them. Microsoft generally makes a best effort to maintain application compatibility as it releases new versions of Windows, but compatibility cannot be guaranteed. It is strongly advised that you perform compatibility testing for your application as new versions of Windows are released in order to be sure that things still work as expected within your application. By loosening OS install conditions, you are essentially putting some of the compatibility testing burden onto users of your application, which can be frustrating for them.
I realize that most Media Center application developers are not WiX or Windows Installer experts, so the above information might be confusing. Please don't hesitate to leave a comment on this blog post or contact me if you have more detailed questions about the scenarios described here or would like an opinion about installation behavior that you are considering for your application.
I recently discovered a useful topic that was published on MSDN as a part of the Open Specifications initiative that I want to link to here in order to hopefully help make it easier to find.
The topic, located at http://msdn.microsoft.com/library/cc231199.aspx, provides a full table of Win32 error code values, their associated message identifiers and descriptions of what the errors mean.
This table of Win32 error codes can be useful in many types of development and troubleshooting scenarios. For example, I often use it in conjunction with the err.exe tool that I described in more detail in this previous blog post to help narrow down root causes when troubleshooting installation issues.
Additional information was announced this morning at Gamefest about Xbox LIVE Community Games. This information expands on the original announcement back in February at GDC by providing more details about how developers will be able to make money by selling their Xbox 360 games created with XNA Game Studio on Xbox LIVE Marketplace.
Here are some links with additional information:
Xbox LIVE Community Games will be available in the holiday 2008 timeframe, but as a developer you can get started now by doing the following:
The setup program for the .NET Framework 3.5 and the Visual Studio 2008 Express Editions contains logic that will cause it to attempt to connect to the Internet to download files in some scenarios. I've heard from several folks who have asked me why this happens and how to prevent it in case they need to install in a fully offline scenario where the system has no Internet connectivity. This post will describe the cases I know of where .NET Framework 3.5 and VS 2008 Express Edition setup will attempt to download files from the Internet and how they can be avoided if necessary.
Case 1 - Missing setup packages
.NET Framework 3.5 and Visual Studio 2008 Express Edition setup both have logic to search in relative paths next to setup.exe for packages that need to be installed during the setup process. If any of the packages are not found in those relative paths, setup will use URL values constructed from information in the setup data file named baseline.dat to attempt to download the packages from the Internet instead. If setup cannot connect to the Internet or the download fails for any reason, then setup will fail and report an error.
In order to avoid requiring Internet access in this scenario, you need to make sure to construct an install point for the .NET Framework 3.5 or the Visual Studio 2008 Express Editions that include all packages that could need to be installed in your environments. You can find more information about how to do this in the following blog posts:
If you are interested, you can find more information about how this automatic download functionality works in .NET Framework 3.5 setup here and here. The VS 2008 Express Edition setup packages use the same setup.exe code as the .NET Framework 3.5 setup, so the behind-the-scenes logic is similar for those packages.
Case 2 - Installing the .NET Framework 3.5 on a non-English OS
The .NET Framework 3.5 setup contains logic to check the language of the OS that it is being installed on and attempt to install a language pack that matches the OS language if one is available. However, the "full install" setup package for the .NET Framework 3.5 does not include any language packs, so setup will attempt to connect to the Internet when this package is run on many non-English language OS's.
In order to avoid requiring Internet access in this scenario, you can use one of the following techniques:
Note - .NET Framework 3.5 setup is configured to report warnings as opposed to failures if it is unable to download or install language packs. That means that the above steps are not required in order to allow setup to succeed in offline scenarios, but these steps are required if you want to avoid any attempts to connect to the Internet during .NET Framework 3.5 setup on non-English operating systems.
Case 3 - Checking for a new version of setup
The setup programs for the .NET Framework 3.5 and the Visual Studio 2008 Express Editions contain logic to cause them to connect to the Internet to search for an updated version of the setup program. This will only happen if setup is run with the /web command line switch. The .NET Framework 3.5 setup program (dotnetfx35setup.exe) and the web download bootstrapper packages for the Visual Studio 2008 Express Editions (vbsetup.exe, vcsetup.exe, vcssetup.exe and vnssetup.exe) are self-extracting packages that are configured to unpack and then run the setup.exe contained within the package with the /web switch.
In order to avoid having .NET Framework 3.5 setup connect to the Internet to search for an updated version of itself, you must do the following:
For the Visual Studio 2008 Express Editions, only the web download bootstrapper packages available from this download page are configured to use the /web switch. If you use the instructions for creating an installable layout in this blog post, you will end up unpacking the package that has the /web switch built into it, and running from the layout you create will not end up searching for a new instance of itself during setup.
Note - .NET Framework 3.5 and VS 2008 Express Edition setups are configured to not fail if they are unable to connect to the Internet to check for a new instance of setup. That means that the above steps are not required in order to allow setup to succeed in offline scenarios, but these steps are required if you want to avoid any attempts to connect to the Internet during .NET Framework 3.5 setup.
The .NET Framework 3.5 setup package is a chainer that installs multiple packages behind the scenes. Before installing anything, it performs an inventory of the state of the system being installed on and decides which packages need to be installed on the system during setup based on what it finds on the system.
The .NET Framework 3.5 Administrator Deployment Guide lists the prerequisite packages that setup installs on each supported OS and describes the command lines that can be used to install them silently, but it does not describe how to determine whether or not a system already has any of the prerequisites installed in order to optimize the deployment process.
The following is a list of all prerequisites for .NET Framework 3.5 setup and the exact logic that .NET Framework 3.5 setup uses behind the scenes to determine whether or not each of them is installed on a user's system, and whether or not setup will block installation if they are not present or will automatically install them for the user.
Note that all of the OS install state, file version and registry version information listed below comes from the file baseline.dat that is included in the .NET Framework 3.5 self-extracting setup package.
Windows XP SP2
On Windows XP systems, .NET Framework 3.5 setup checks the following registry value to determine the OS service pack state:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows] CSDVersion >= 512
Setup will block if the necessary service pack is not found, and the user must manually update their system before setup can proceed.
Windows Server 2003 SP1
On Windows Server 2003 systems, .NET Framework 3.5 setup checks the following registry value to determine the OS service pack state:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows] CSDVersion >= 256
Windows Installer 3.1
.NET Framework setup only checks for this prerequisite on Windows XP because the necessary Windows Installer version is a part of the OS on other supported platforms. To determine installation state, it checks the version of the following file:
%windir%\system32\msi.dll >= 3.1.4000.2435
Setup will block if the necessary version is not found, and the user must manually update their system before setup can proceed.
Software rasterizer for the DirectX 9.0 SDK (RGB Rasterizer)
.NET Framework 3.5 setup only attempts to install this component on Windows XP and Windows Server 2003. To determine installation state, it checks the version of the following file:
%windir%\system32\rgb9rast_2.dll >= 9.15.735.0
Setup will install this package if the necessary version is not found on the system.
MSXML 6.0
%windir%\system32\msxml6.dll >= 6.0.3888.0
Windows Imaging Component
%windir%\system32\windowscodecs.dll >= 6.0.5840.16388
.NET Framework 2.0 SP1 (Windows XP and Windows Server 2003)
On Windows XP and Windows Server 2003, .NET Framework 3.5 setup checks for the existence of the MSI-based version of the .NET Framework 2.0 SP1. To determine installation state, it checks the following registry value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727] Version >= 2.1.21022
.NET Framework 2.0 SP1 (Windows Vista and Windows Server 2008)
On Windows Vista and Windows Server 2008, .NET Framework 3.5 setup checks for the existence of the .NET Framework 2.0 SP1 OS update package because the .NET Framework 2.0 is an OS component on these OS's. To determine installation state, it checks the version of the following file:
%windir%\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll >= 2.0.50727.1433
XML Paper Specification Shared Components (XPS)
%windir%\system32\prntvpt.dll >= 6.0.6000.16438
.NET Framework 3.0 OS component (Windows Vista and Windows Server 2008)
On Windows Vista and Windows Server 2008, .NET Framework 3.5 setup checks for the existence of the .NET Framework 3.0 component that ships as a part of the OS. To determine installation state, it checks the following registry value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0\Setup] InstallSuccess = 1
If the .NET Framework 3.0 SP1 OS component is not found on the system, setup will use a technique like the one described in this blog post to cause the OS to install the component.
.NET Framework 3.0 SP1 (Windows XP and Windows Server 2003)
On Windows XP and Windows Server 2003, .NET Framework 3.5 setup checks for the existence of the MSI-based version of the .NET Framework 3.0 SP1. To determine installation state, it checks the following registry value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0] Version >= 3.1.21022
.NET Framework 3.0 SP1 (Windows Vista and Windows Server 2008)
On Windows Vista and Windows Server 2008, .NET Framework 3.5 setup checks for the existence of the .NET Framework 3.0 SP1 OS update package because the .NET Framework 3.0 is an OS component on these OS's. To determine installation state, it checks the following registry value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0\Setup] Version >= 3.0.04506.648
.NET Framework 3.5
On all supported operating systems, .NET Framework 3.5 setup checks for the existence of the main .NET Framework 3.5 MSI package. To determine installation state, it checks the following registry value:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5] Version >= 3.5.21022.08
Additional information
The .NET Framework 2.0 SP1 and .NET Framework 3.0 SP1 also ship as standalone installation packages that can be installed independently from the .NET Framework 3.5. Each of these packages includes a subset of the above prerequisites and uses the same logic described above to determine whether or not each prerequisite is already installed. The following is a list of which of the above prerequisites are required for the .NET Framework 2.0 SP1 and 3.0 SP1:
Prerequisites for the .NET Framework 2.0 SP1:
Prerequisites for the .NET Framework 3.0 SP1:
Here are links to some additional useful information related to .NET Framework 3.5 deployment:
I recently noticed a blog article from the Zman that I wanted to link to here to hopefully make it easier to find. The post, located at http://www.thezbuffer.com/articles/541.aspx, provides some behind-the-scenes details about the contents of XNA Game Studio and XNA Game Studio Express .csproj files. The project GUIDs and XNA Framework version information listed in this post can help you determine exactly what version of XNA Game Studio or XNA Game Studio Express a specific .csproj file was created with.
If you run into an error message stating "The project type is not supported by this installation" when attempting to open an XNA Game Studio project in Visual Studio 2005 or 2008 and are trying to figure out how to fix it, the information in this article can be very helpful. Typically, this error occurs when trying to open XNA Game Studio projects for one of the following reasons:
If you run into an error while trying to open an XNA Game Studio or XNA Game Studio Express project on your system, I encourage you to check out this article and use the information listed there to determine the XNA Game Studio version of the project that you're trying to open by looking at your .csproj file in Notepad, then verify that the necessary versions of both Visual Studio and XNA Game Studio are installed on your system.
For reference, here is a list of supported Visual Studio platforms per version of XNA Game Studio:
Question:
I am creating an application that is built on the .NET Framework 2.0, and I am attempting to create an MSI-based installer for it. I have seen documentation and sample code describing how to detect the presence of individual versions of the .NET Framework. My application does not require a specific version of the .NET Framework, but has a minimum version of 2.0, so I would like to detect the presence of the .NET Framework 2.0 or later in order to try to avoid needing to update my installation logic each time the .NET Framework ships a new version. How can I do this?
Answer:
There is not an officially supported way of checking for the presence of a range of .NET Framework versions. There are supported ways of checking for each version that has been released, but this logic can only be used to determine whether or not that exact version is installed. This logic cannot necessarily be used to infer anything about other versions of the .NET Framework. In particular, it is not possible to know ahead of time what types of detection logic will be needed for versions of the .NET Framework that have not yet been released.
As a result, it is most reliable to have your application's installer check for specific versions of the .NET Framework that you have tested your application against and that you know your application is compatible with. Then, you can update your installer logic if you need to support additional versions of the .NET Framework as they are released in the future.
Admittedly, it is not ideal to have to update your installer as new versions of the .NET Framework are released, but it is the only way to be sure that your detection logic will return the correct result for .NET Framework install state checks in the future. As a side benefit, the process of updating your installer will also help ensure that you perform the necessary compatibility testing to ensure that your application continues to work as expected when installed on a system that only has some future version of the .NET Framework that was not available to test against when your application originally shipped.
For reference, here are a few ways that I have seen various setups use in order to attempt to implement a "greater than or equal" check for versions of the .NET Framework along with reasons why they are not reliable:
A note for WiX users
If you are using WiX v3.0 to create MSI-based installers, there are some built-in properties in the WixNetFxExtension that can be included in your setup authoring to detect the presence of all currently released versions of the .NET Framework. You can find a how-to help topic describing how to check for versions of the .NET Framework in an MSI-based setup using WiX v3.0 in builds 3.0.4220.0 or higher of WiX v3.0. You can download WiX builds at http://wix.sourceforge.net/releases. In the table of contents in WiX.chm (which is located in wix3-binaries.zip for each build of WiX), the topic is located under WiX Help | How To Guides | Redistributables and Install Checks | How To: Check for .NET Framework Versions.
In my previous blog post, I described silent repair and uninstall command line switches that can be used for the .NET Framework 3.5. In that post, I also noted that because the .NET Framework 3.5 includes the .NET Framework 2.0 SP1 and 3.0 SP1 as prerequisites, the repair process would chain in the repair for the .NET Framework 2.0 SP1 and 3.0 SP1 as well.
As a few people have already noticed, that statement is only true when running .NET Framework 3.5 repair on operating systems prior to Windows Vista. Specifically, the supported pre-Vista OS's for the .NET Framework 3.5 are Windows XP (with SP2 or later) and Windows Server 2003. On pre-Vista OS's, the .NET Framework 2.0 SP1 and 3.0 SP1 are installed using MSI-based packages.
On Windows Vista and Windows Server 2008, the .NET Framework 2.0 and 3.0 are OS components, so any updates to the .NET Framework 2.0 and 3.0 must be installed via OS updating technologies instead of by MSI-based packages. Unfortunately, the OS updating logic does not allow the packages to be re-run to perform a repair. Instead you have to uninstall and then reinstall the packages. Because of this OS update behavior, running a repair of the .NET Framework 3.5 on Windows Vista will skip attempting to repair the .NET Framework 2.0 SP1 and 3.0 SP1 in order to avoid scenarios that we know will report failures.
How to uninstall and re-install 2.0 SP1 and 3.0 SP1 on Windows Vista
There is not an easy way to repair the .NET Framework 2.0 SP1 or 3.0 SP1 on Windows Vista. If you are running Windows Vista without Vista SP1, you can uninstall the .NET Framework 2.0 SP1 and 3.0 SP1 using the following steps, and then perform a repair of the .NET Framework 3.5 to re-install them:
Important note about Windows Vista SP1 and Windows Server 2008
The .NET Framework 2.0 SP1 and 3.0 SP1 packages are integrated into Windows Vista SP1 and Windows Server 2008, so they are not available separately in the Programs and Features control panel like they are for Windows Vista without SP1.
This means that you must use one of the following options to attempt to repair the .NET Framework 2.0 SP1 and 3.0 SP1 on Windows Vista SP1 and Windows Server 2008: