Aaron Stebner's WebLog

Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio

July, 2008

  • Aaron Stebner's WebLog

    Scenarios where .NET Framework 3.5 setup tries to connect to the Internet and how to avoid them

    • 30 Comments

    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:

    • Download the .NET Framework 3.5 language packs that could be needed in your environments and copy them into your installable .NET Framework 3.5 layout.  You can find download locations for the .NET Framework 3.5 language packs in this blog post and instructions regarding where to copy them in your .NET Framework 3.5 installable layout in item 2 in this blog post.
    • Run .NET Framework 3.5 setup with the /lang switch and pass in the value ENU to prevent it from attempting to install any language packs.  This is described in item 1 in this blog post.

    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:

    1. Create an installable layout using the steps in this blog post
    2. Go to the folder that you extracted the .NET Framework 3.5 setup files to, find the file named dotnetfx35setup.exe and run dotnetfx35setup.exe /x to unpack it
    3. When prompted, choose to unpack it to the same folder it is currently located in
    4. Instead of using the file dotnetfx35setup.exe to start installing the .NET Framework 3.5, use the file setup.exe in the unpacked location.  This will cause setup to run without the /web switch and skip the step of connecting to the Internet to search for a new copy of setup.  The setup.exe file takes the same command line parameters as dotnetfx35setup.exe (such as the /q and /norestart switches for silent installation).

    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.

  • Aaron Stebner's WebLog

    How .NET Framework 3.5 setup checks for its prerequisites behind the scenes

    • 15 Comments

    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

    Setup will block if the necessary service pack is not found, and the user must manually update their system before setup can proceed.

    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

    .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\msxml6.dll >= 6.0.3888.0

    Setup will install this package if the necessary version is not found on the system.

    Windows Imaging Component

    .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\windowscodecs.dll >= 6.0.5840.16388

    Setup will install this package if the necessary version is not found on the system.

    .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

    Setup will install this package if the necessary version is not found on the system.

    .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

    Setup will install this package if the necessary version is not found on the system.

    XML Paper Specification Shared Components (XPS)

    .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\prntvpt.dll >= 6.0.6000.16438

    Setup will install this package if the necessary version is not found on the system.

    .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

    Setup will install this package if the necessary version is not found on the system.

    .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

    Setup will install this package if the necessary version is not found on the system.

    .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

    Setup will install this package if the necessary version is not found on the system.

    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:

    • Windows XP SP2
    • Windows Server 2003 SP1
    • Windows Installer 3.1

    Prerequisites for the .NET Framework 3.0 SP1:

    • Windows XP SP2
    • Windows Server 2003 SP1
    • Windows Installer 3.1
    • Software rasterizer for the DirectX 9.0 SDK (RGB Rasterizer)
    • MSXML 6.0
    • Windows Imaging Component
    • .NET Framework 2.0 SP1 (Windows XP and Windows Server 2003)
    • .NET Framework 2.0 SP1 (Windows Vista and Windows Server 2008)
    • XML Paper Specification Shared Components (XPS)
    • .NET Framework 3.0 OS component (Windows Vista and Windows Server 2008)

    Here are links to some additional useful information related to .NET Framework 3.5 deployment:

  • Aaron Stebner's WebLog

    How to use WiX to create an MSI-based installer that will install the DirectX 9.0 redistributable

    • 2 Comments

    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.

    How To: Install DirectX 9.0 With Your Installer

    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.

    Step 1: Add the installer files to your WiX project

    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:

    <DirectoryRef Id="APPLICATIONROOTDIRECTORY">
        <Directory Id="DirectXRedistDirectory" Name="DirectX9.0c">
            <Component Id="DirectXRedist" Guid="PUT-GUID-HERE">
                <File Id="DXSETUPEXE"
                        Source="MySourceFiles\DirectXMinInstall\dxsetup.exe"
                        KeyPath="yes"
                        Checksum="yes"/>
                <File Id="dxupdate.cab"
                        Source="MySourceFiles\DirectXMinInstall\dxupdate.cab"/>
                <File Id="dxdllreg_x86.cab"
                        Source="MySourceFiles\DirectXMinInstall\dxdllreg_x86.cab"/>
                <File Id="dsetup32.dll"
                        Source="MySourceFiles\DirectXMinInstall\dsetup32.dll"/>
                <File Id="dsetup.dll"
                        Source="MySourceFiles\DirectXMinInstall\dsetup.dll"/>
                <File Id="DEC2006_d3dx9_32_x86.cab"
                        Source="MySourceFiles\DirectXMinInstall\DEC2006_d3dx9_32_x86.cab"/>
            </Component>
        </Directory>
    </DirectoryRef>
    
    <Feature Id="DirectXRedist"
                  Title="!(loc.FeatureDirectX)"
                  AllowAdvertise="no"
                  Display="hidden" Level="1">
        <ComponentRef Id="DirectXRedist"/>
    </Feature>

    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.

    Step 2: Add a custom action to invoke the 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.

    <CustomAction Id="InstallDirectX"
                           FileKey="DXSETUPEXE"
                           ExeCommand="/silent"
                           Execute="deferred"
                           Impersonate="no"
                           Return="check"/>
    
    <InstallExecuteSequence>
        <Custom Action="InstallDirectX" Before="InstallFinalize">
            <![CDATA[NOT REMOVE]]>
        </Custom>
    </InstallExecuteSequence>

    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.

    Step 3: Include progress text for the custom action

    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.

    <UI>
        <ProgressText Action="InstallDirectX">Installing DirectX 9.0c</ProgressText>
    </UI>

    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.exe
    warning 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>

     

  • Aaron Stebner's WebLog

    Link to System Update Readiness Tool for Windows Vista and Windows Server 2008 that can help fix OS update install errors

    • 1 Comments

    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:

    • Installing the original release of the .NET Framework 3.5 on the original release of Windows Vista
    • Installing the .NET Framework 3.5 SP1 on Windows Vista SP1
    • Installing the .NET Framework 3.5 SP1 on Windows Server 2008

    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>

     

  • Aaron Stebner's WebLog

    Some notes about OS installation conditions in Media Center application setup files

    • 1 Comments

    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:

    1. NOT VersionNT = 600 - This checks the built-in Windows Installer property named VersionNT to make sure it is equal to 600, and will cause setup to block if it is not.  This is primarily designed to prevent the MSI from installing on older versions of Windows such as Windows XP Media Center Edition (which will have VersionNT = 501), but will also end up preventing installation on future versions of Windows that have the VersionNT value set to something higher than 600 as well.
    2. NOT MCEINSTALLVERSION = "5.0" - This queries the Ident registry value located at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Media Center and will cause setup to block if the value does not exist or is not equal to 5.0.  This is primarily designed to prevent the MSI from installing on versions of Windows that do not include Windows Media Center features or from installing on systems that have older versions of Media Center (see the chart of Ident values here for more information).  However, it will also end up preventing installation on systems if they have future versions of Windows Media Center that have the Ident value set to something higher than 5.0 as well.
    3. NOT REGISTERMCEAPP - this condition checks to make sure that the file %windir%\eHome\RegisterMceApp.exe exists on the system and has a version number at least 6.0.0.0.  This will make sure that at least the Windows Vista version of RegisterMceApp.exe is on the system because it is needed during setup to register the application for use in Windows Media Center.
    4. NOT Installed - this condition is a standard Windows Installer condition that is typically added to blocking custom actions such as this one.  It detects whether or not the current product is already installed, and is intended to prevent the user from being blocked when trying to uninstall the product.

    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:

    • NOT VersionNT >= 600 - This condition will cause the MSI to only block on any version of Windows prior to Vista.  It will no longer block on any potential future versions of Windows with a VersionNT value greater than 600.
    • NOT MCEINSTALLVERSION - This condition will cause the MSI to only block if the Ident registry value does not exist, but will not check the exact Ident version value.  It will no longer block on any potential future version of Windows Media Center with an Ident value not equal to 5.0.  It could also theoretically run on an older version of Windows Media Center, but you should be protected by the VersionNT check in that case to avoid the MSI running on Windows XP Media Center Edition for example.  I chose not to put a greater than or equal check here because the Ident value is a REG_SZ data type in the registry, and greater than or equal checks on strings tend to not always be accurate (for example "10.0" is less than "2.0" when doing string comparisons).

    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.

     

  • Aaron Stebner's WebLog

    More details about Xbox LIVE Community Games

    • 1 Comments

    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:

    1. Download and install XNA Game Studio
    2. Join the XNA Creators Club so that you can develop and submit your Xbox 360 game.  You will need a premium membership (as described here).
    3. Prepare to submit your game when Xbox LIVE Community Games is available
  • Aaron Stebner's WebLog

    .NET Framework 2.0 SP1 and 3.0 SP1 repair options on Windows Vista and Windows Server 2008

    • 1 Comments

    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:

    1. Go to the Programs and Features control panel
    2. Click on the link at the top left labeled View installed updates
    3. To remove the .NET Framework 3.0 SP1, find the item named Update for Microsoft Windows (KB929300), right-click on it and choose Uninstall
    4. To remove the .NET Framework 2.0 SP1, find the item named Update for Microsoft Windows (KB110806), right-click on it and choose Uninstall
    5. Repair the .NET Framework using the steps in this blog post to restore the .NET Framework 2.0 SP1 and 3.0 SP1

    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:

    1. If you installed the standalone Windows Vista SP1 update package (as opposed to purchasing a computer with Windows Vista with SP1 pre-installed), you can attempt to repair or re-install Windows Vista SP1 to repair all components of SP1, including the .NET Framework 2.0 SP1 and 3.0 SP1
    2. If you have a computer that came pre-installed with Windows Vista SP1 or a computer with Windows Server 2008, there is not a separate update package that can be repaired.  You can use steps like the ones in this knowledge base article (KB929833) to repair the files that are a part of the OS (including the .NET Framework 2.0 SP1 and 3.0 SP1 payload).  The only way to perform a full repair of all components of the .NET Framework 2.0 SP1 and 3.0 SP1 (registry keys, services, etc and not just the files) is to repair or re-install Windows Vista or Windows Server 2008 themselves.
  • Aaron Stebner's WebLog

    Mailbag: How can I detect the presence of the .NET Framework 2.0 or later in my MSI-based installer?

    • 0 Comments

    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:

    • Check for the presence of the .NET Framework 2.0 using the documented detection registry value in order to detect the .NET Framework 2.0 or higher.  This check happens to work for the .NET Framework 3.0 and 3.5 because 3.0 and 3.5 are not truly new versions of the .NET Framework (meaning - they do not update the underlying CLR), and 3.0 and 3.5 both require 2.0 to be installed before they allow the user to install.  However, this logic is not necessarily going to be true in future versions of the .NET Framework and there will likely eventually be a new version of the CLR that will cause this type of check to return incorrect results on a system that does not also have the .NET Framework 2.0 installed.
    • Check the value of the Windows Installer MsiNetAssemblySupport property.  This property is set to the version number of fusion.dll for the latest version of the CLR that is installed on the system.  This property does not get updated to a version greater than 2.0 when installing the .NET Framework 3.0 or 3.5 because both 3.0 and 3.5 use the 2.0 version of the CLR.  As a result, this property cannot currently be used to distinguish any versions of the .NET Framework greater than 2.0.  In addition, using this property may also not return the correct installation state needed for your application if the .NET Framework client profile is installed on the system but a full version of the .NET Framework is not installed.  For example, if your application requires a part of the .NET Framework not included in the client profile, but you use the MsiNetAssemblySupport property to detect the .NET Framework, it may return true when in reality the full version of the .NET Framework needed by your application is not present on the system.
    • Check the version number of %windir%\system32\mscoree.dll.  This file is shared by all versions of the CLR and will have a file version equal to the highest installed version of the CLR on the system.  This file will still have a 2.0 version after installing the .NET Framework 3.0 or 3.5 because both 3.0 and 3.5 use the 2.0 version of the CLR.  As a result, this file cannot currently be used to distinguish any versions of the .NET Framework greater than 2.0.  In addition, using this file may also not return the correct installation state needed for your application if the .NET Framework client profile is installed on the system but a full version of the .NET Framework is not installed.  For example, if your application requires a part of the .NET Framework not included in the client profile, but you use the file version of mscoree.dll to detect the .NET Framework, it may return true when in reality the full version of the .NET Framework needed by your application is not present on the system.

    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.

  • Aaron Stebner's WebLog

    Version information that can help diagnose errors when opening XNA Game Studio projects in Visual Studio

    • 0 Comments

    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:

    • Trying to double-click an XNA Game Studio project (.csproj) file on a system that does not have the matching version of XNA Game Studio or XNA Game Studio Express installed.
    • Trying to open a project from within a version of Visual Studio that is not supported by the version of XNA Game Studio that the project was created in (for example - opening an XNA Game Studio 2.0 project in Visual Studio 2008).
    • Trying to open a XNA Game Studio Express 1.0 or 1.0 Refresh project on a system that has an up-level edition of Visual Studio 2005 installed but does not have Visual C# 2005 Express Edition installed - this will cause the solution to open in the up-level edition of Visual Studio 2005, but XNA Game Studio did not support up-level editions of VS until XNA Game Studio 2.0.  Projects for the 1.0 or 1.0 Refresh versions must be opened on a system that has Visual C# 2005 Express Edition and XNA Game Studio 1.0 or 1.0 Refresh installed.

    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:

  • Aaron Stebner's WebLog

    Link to MSDN topic with descriptions of all Win32 error codes

    • 0 Comments

    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.

  • Aaron Stebner's WebLog

    Links to 3 new community spotlight features on the XNA Creators Club Web site

    • 0 Comments

    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.

Page 1 of 1 (11 items)