Aaron Stebner's WebLog

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

May, 2009

  • Aaron Stebner's WebLog

    How to unblock installation of the .NET Framework 4 beta 1 on Windows XP Media Center and Tablet PC Editions

    • 13 Comments

    Question:

    I tried to install the .NET Framework 4 beta 1 and Visual Studio 2010 beta 1 on my Windows XP Media Center system.  It fails to install with an error like the following:

    Microsoft .NET Framework 4 Beta 1 cannot be installed because an incompatible version of .NET Framework (v1.0) is installed on the machine. For more information, see http://go.microsoft.com/fwlink/?LinkId=91126.

    I don’t see any useful information in that link, and I don’t see an option to uninstall the .NET Framework 1.0 in the Add/Remove Programs control panel on my system, so I’m stuck.

    Is there any way I can install the .NET Framework 4 beta 1 and VS 2010 beta 1 on my Windows XP Media Center system?

    Answer:

    Officially, the .NET Framework 4 beta 1 (and therefore VS 2010 beta 1) is not supported on Windows XP Media Center Edition or Windows XP Tablet PC Edition.  However, the wording in the readme is a bit vague.  Item 2.1.1.1 in the .NET Framework 4 beta 1 readme says the following:

    Note: You cannot install the .NET Framework 4 Beta 1 on operating systems that have the .NET Framework 1.0 built in.

    As I previously wrote in this blog post, the .NET Framework 1.0 is installed as an OS component on Windows XP Media Center Edition and Windows XP Tablet PC Edition, and it cannot be uninstalled on those versions of Windows XP.

    If you are running Windows XP Media Center Edition or Windows XP Tablet PC Edition and want to be able to install the .NET Framework 4 beta 1 and VS 2010 beta 1, you can manually rename the following registry value:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v1.0]

    If you do this, there are a few important caveats to keep in mind:

    • Renaming this registry key will cause the .NET Framework 1.0 to not function correctly in some cases.  This is why I suggest renaming the key instead of deleting it.  If you rename it, you can restore it in the future.  You can rename it back immediately after installing the .NET Framework 4 beta 1, but this key will also prevent you from uninstalling the .NET Framework 4 beta 1, so if you do that, you will need to rename it again prior to uninstalling this beta.
    • Renaming this registry key was not officially tested by the Visual Studio and .NET Framework teams, so if you decide to do this, you do so at your own risk and you may run into unforeseen problems.
    • If you delete the above registry key and find that you need to restore it later in order to fix functional problems with the .NET Framework 1.0, you can use the steps in this blog post to repair the version of the .NET Framework 1.0 that is installed as an OS component on Windows XP Media Center Edition and Windows XP Tablet PC Edition.  Alternatively, you can manually re-create the following registry key that is listed in this blog post:

      [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Policy\v1.0]
      3705 = 3321-3705
  • Aaron Stebner's WebLog

    Using WiX 3.0 to create an MSI-based installer for Visual Studio project templates

    • 2 Comments

    A while back, I wrote a blog post where I introduced a set of Visual Studio 2005 and 2008 project templates that I created to supplement the ones that shipped in one of the earlier versions of the Windows Vista Media Center SDK.  I used WiX v3.0 to create the installer for these project templates.  The process of creating an MSI-based installer for Visual Studio project templates can be a bit tricky at first, so I wanted to walk through an example that demonstrates the steps to create an MSI to install and register Visual Studio project templates in order to hopefully make it easier for folks to create their own installers for Visual Studio project templates in the future.

    I previously posted a set of instructions that describe how to use WiX v2.0 to create installers for Visual Studio project templates.  This time, I am going to post snippets of the WXS file directly in this post and explain what each of the pieces of this installer is doing in more detail.

    I chose to use WiX v3.0 in this example for a couple of key reasons that will make more sense when we walk through the WXS code below:

    • The WixVSExtension contains a set of built-in detection and properties and custom actions for locating versions of Visual Studio and registering new project templates for use in the IDE.  This will save us a lot of work because we won’t have to author these properties and custom actions ourselves.
    • WiX v3.0 contains a new feature called smart cabbing (introduced by Rob Mensching in this blog post).  This feature will optimize package sizes by not including duplicate copies of the same files in the cabs created during the build process.  This is particularly useful for Visual Studio project templates because in many cases, the same project template zip file will be installed to different locations (such as the Visual Studio 2005 template location, the Visual C# 2005 Express template location, the Visual Studio 2008 template location, etc).  Smart cabbing allows us to carry only one copy of each project template zip file, even if we install it for multiple versions or editions of Visual Studio.

    I have posted a downloadable copy of the example that I’m going to use in this blog post at http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog%7C_Tools/WiX%20Samples/wix%7C_sample%7C_vs%7C_project%7C_template%7C_installer.zip.  It contains the following information:

    • WiX source files that describe how to build the MSI
    • Project template zip files (the payload of the MSI)
    • A build script that calls Candle and Light (the WiX compiler and linker) to create the MSI
    • A built copy of the sample MSI

    For the rest of this post, I will be walking through the syntax of the file wix_sample_vs_project_template_installer.wxs that is included in the above zip file and that I also posted as a standalone file at http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog%7C_Tools/WiX%20Samples/wix%7C_sample%7C_vs%7C_project%7C_template%7C_installer.wxs if you need to quickly reference it without downloading and extracting the entire zip file.

    Import WiX Visual Studio 2005 detection properties and registration custom actions

    WiX v3.0 includes a set of built-in detection properties and custom actions for the Visual Studio 2005 family of products.  When building your project template installer, you will need to decide which (if any) Visual Studio 2005 products that you plan to support, and then import the appropriate properties and custom actions.

    In the example I created, the following statements are used to import the Visual C# 2005 Express Edition, Visual Basic 2005 Express Edition and Visual Studio 2005 Standard Edition and higher detection properties and registration custom actions:

    <PropertyRef Id="VS2005_ROOT_FOLDER" />
    <PropertyRef Id="VS2005_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED" />
    <PropertyRef Id="VS2005_IDE_VB_PROJECTSYSTEM_INSTALLED" />

    <CustomActionRef Id="VS2005Setup" />
    <CustomActionRef Id="VCSHARP2005Setup" />
    <CustomActionRef Id="VB2005Setup" />

    Import WiX Visual Studio 2008 detection properties and registration custom actions

    WiX v3.0 includes a set of built-in detection properties and custom actions for the Visual Studio 2008 family of products.  When building your project template installer, you will need to decide which (if any) Visual Studio 2008 products that you plan to support, and then import the appropriate properties and custom actions.

    In the example I created, the following statements are used to import the Visual C# 2008 Express Edition, Visual Basic 2008 Express Edition and Visual Studio 2008 Standard Edition and higher detection properties and registration custom actions:

    <PropertyRef Id="VS90_ROOT_FOLDER" />
    <PropertyRef Id="VS90_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED" />
    <PropertyRef Id="VS90_IDE_VB_PROJECTSYSTEM_INSTALLED" />

    <CustomActionRef Id="VS90Setup" />
    <CustomActionRef Id="VCSHARP90Setup" />
    <CustomActionRef Id="VB90Setup" />

    Define the Visual Studio 2005 and Visual Studio 2008 templates directory structure

    The next step is to define the installation folder structure for the templates.  You need to define a default folder structure that matches the default installation directories for each of the versions of Visual Studio that you plan to support, and then also include logic to allow your project template installer to install the templates to the correct location if it detects that Visual Studio is installed to a non-default location.

    In the example I created, the following folder structure is used for Visual Studio 2005 project templates.  The Id named VS2005_ROOT_FOLDER matches one of the built-in WiX properties defined above, and it will be set to a non-default location during installation if the user has Visual Studio 2005 installed to a non-default location on their system:

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder" Name="Program Files">
        <Directory Id="VS2005_ROOT_FOLDER" Name="Visual Studio 8">
          <Directory Id="Common7_2005" Name="Common7">
            <Directory Id="IDE_2005" Name="IDE">
              <Directory Id="ProjectTemplates_VS_2005" Name="ProjectTemplates">
                <Directory Id="CSharpProjectTemplates_VS_2005" Name="CSharp">
                  <Directory Id="MceProjectTemplates_Csharp_VS_2005" Name="Windows Media Center"/>
                </Directory>
                <Directory Id="VBasicProjectTemplates_VS_2005" Name="VisualBasic">
                  <Directory Id="MceProjectTemplates_VBasic_VS_2005" Name="Windows Media Center"/>
                </Directory>
              </Directory>
              <Directory Id="VcsExpress_2005" Name="VcsExpress">
                <Directory Id="ProjectTemplates_VCS_Express_2005" Name="ProjectTemplates"/>
              </Directory>
              <Directory Id="VbExpress_2005" Name="VbExpress">
                <Directory Id="ProjectTemplates_VB_Express_2005" Name="ProjectTemplates"/>
              </Directory>
            </Directory>
          </Directory>
        </Directory>
      </Directory>
    </Directory>

    In the example I created, the following folder structure is used for Visual Studio 2008 project templates.  The Id named VS90_ROOT_FOLDER matches one of the built-in WiX properties defined above, and it will be set to a non-default location during installation if the user has Visual Studio 2008 installed to a non-default location on their system:

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder" Name="Program Files">
        <Directory Id="VS90_ROOT_FOLDER" Name="Visual Studio 9.0">
          <Directory Id="Common7_2008" Name="Common7">
            <Directory Id="IDE_2008" Name="IDE">
              <Directory Id="ProjectTemplates_VS_2008" Name="ProjectTemplates">
                <Directory Id="CSharpProjectTemplates_VS_2008" Name="CSharp">
                  <Directory Id="MceProjectTemplates_Csharp_VS_2008" Name="Windows Media Center"/>
                </Directory>
                <Directory Id="VBasicProjectTemplates_VS_2008" Name="VisualBasic">
                  <Directory Id="MceProjectTemplates_VBasic_VS_2008" Name="Windows Media Center"/>
                </Directory>
              </Directory>
              <Directory Id="VcsExpress_2008" Name="VcsExpress">
                <Directory Id="ProjectTemplates_VCS_Express_2008" Name="ProjectTemplates"/>
              </Directory>
              <Directory Id="VbExpress_2008" Name="VbExpress">
                <Directory Id="ProjectTemplates_VB_Express_2008" Name="ProjectTemplates"/>
              </Directory>
            </Directory>
          </Directory>
        </Directory>
      </Directory>
    </Directory>

    Define components to install each of the Visual Studio project templates

    Now that you have defined the installation folder structure, the next step is to define Windows Installer components for each of the project templates you want to install.  There are a few considerations to keep in mind when doing this:

    1. If you plan to support multiple versions or editions of Visual Studio, it is a good idea to put installation conditions on each component so the component will only be installed if the version/edition of Visual Studio that it applies to is present on the user’s system.
    2. If you have any conditions in the component, you should set Transitive=”yes” for that component in your WiX authoring.  The transitive attribute will cause Windows Installer to re-evaluate the condition during a repair.  That is useful if the user installs your product, then adds a new Visual Studio edition and tries to repair your product.  Setting the transitive attribute will allow your product to add your project templates to the newly installed Visual Studio edition during a repair of your product.  If you don’t set the transitive attribute, the user would have to uninstall and then re-install your product to add your project templates to the newly installed Visual Studio edition.
    3. It is possible for a user to install Visual Studio but not install all of the language tools.  Therefore, if you have a C# project template, it is a best practice to not only check to see if Visual Studio is installed, but also to see if the C# project system is installed within Visual Studio.  The same holds true for project templates for other languages (VB, VC++, etc).
    4. If you plan to support both Visual Studio Standard Edition and higher and Visual Studio Express Editions, you should check for the existence of both the Visual Studio root directory (which can be created by either Visual Studio or Express Editions) and the Visual Studio executable for the exact  edition of Visual Studio that the template will be used by.  For example, in a Visual C# Express template, you would check for vcsexpress.exe, and in a Visual Studio Standard Edition or higher template, you would check for devenv.exe.

    In the example I created, the following component is used to install a C# project template for use in Visual Studio 2005 Standard Edition and higher.  Note that it implements the 4 suggestions listed above by including a condition that checks for the VS 2005 root folder, the file devenv.exe and the Visual C# project system and marking the component as transitive:

    <DirectoryRef Id="MceProjectTemplates_Csharp_VS_2005">
      <Component Id="MediaCenterApplicationFundamental_csharp.zip_VS_2005" Guid="{75055686-A7E2-401F-B288-2EC6067E7F7B}" DiskId="1" Transitive="yes">
        <Condition>(VS2005_ROOT_FOLDER AND VS2005DEVENV AND VS2005_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED)</Condition>
        <File Id="MediaCenterApplicationFundamental_csharp.zip_VS_2005" Name="MediaCenterApplicationFundamental.zip" KeyPath="yes" Source="MediaCenterApplicationFundamental_csharp.zip"/>
      </Component>
    </DirectoryRef>

    In the example I created, the following component is used to install the same project template as the one above, but to install it for use in Visual C# 2005 Express Edition instead of Visual Studio 2005 Standard Edition and higher.  Visual Studio Express Editions do not have selectable features, so there is no need to check that the Visual C# project system is installed in this component.

    <DirectoryRef Id="ProjectTemplates_VCS_Express_2005">
      <Component Id="MediaCenterApplicationFundamental_csharp.zip_VCS_2005" Guid="{193E3610-90C5-442C-ACF7-D50C67B4B27C}" DiskId="1" Transitive="yes">
        <Condition>(VS2005_ROOT_FOLDER AND VCSHARP2005EXPRESS_IDE)</Condition>
        <File Id="MediaCenterApplicationFundamental_csharp.zip_VCS_2005" Name="MediaCenterApplicationFundamental.zip" KeyPath="yes" Source="MediaCenterApplicationFundamental_csharp.zip"/>
      </Component>
    </DirectoryRef>

    In the example I created, the following component is used to install the same project template as the one above, but to install it for use in Visual Studio 2008 Standard Edition and higher.

    <DirectoryRef Id="MceProjectTemplates_Csharp_VS_2008">
      <Component Id="MediaCenterApplicationFundamental_csharp.zip_VS_2008" Guid="{70AE985D-706A-4C39-9417-20303DA605AC}" DiskId="1" Transitive="yes">
        <Condition>(VS90_ROOT_FOLDER AND VS90DEVENV AND VS90_IDE_VCSHARP_PROJECTSYSTEM_INSTALLED)</Condition>
        <File Id="MediaCenterApplicationFundamental_csharp.zip_VS_2008" Name="MediaCenterApplicationFundamental.zip" KeyPath="yes" Source="MediaCenterApplicationFundamental_csharp.zip"/>
      </Component>
    </DirectoryRef>

    In the example I created, the following component is used to install the same project template as the one above, but to install it for use in Visual C# 2008 Express Edition.

    <DirectoryRef Id="ProjectTemplates_VCS_Express_2008">
      <Component Id="MediaCenterApplicationFundamental_csharp.zip_VCS_2008" Guid="{92C85077-C8EB-40F9-82F3-1887B9EA111E}" DiskId="1" Transitive="yes">
        <Condition>(VS90_ROOT_FOLDER AND VCSHARP90EXPRESS_IDE)</Condition>
        <File Id="MediaCenterApplicationFundamental_csharp.zip_VCS_2008" Name="MediaCenterApplicationFundamental.zip" KeyPath="yes" Source="MediaCenterApplicationFundamental_csharp.zip"/>
      </Component>
    </DirectoryRef>

    All 4 of the above components use the same Source value in the File element, so the WiX v3.0 smart-cabbing feature will optimize the build process to include only one copy of the project template .zip file in your installer payload.  This can save a lot of disk space when creating installers for Visual Studio project templates that target multiple versions/editions of Visual Studio.

    Block installation if the necessary version of Visual Studio is not installed

    In addition to including component conditions, I also suggest that you include blocking logic in your project template installer if none of the supported Visual Studio editions/versions are installed on the user’s system.  If your project template installer only supports a single edition and version of Visual Studio, this type of block is simple to author.  However, if you plan to support multiple editions and/or versions of Visual Studio, you need to carefully author the block so it won’t be overly aggressive.

    In the example I created, the project templates support all of the following: Visual Studio 2005 Standard Edition and higher, Visual C# 2005 Express Edition, Visual Basic 2005 Express Edition, Visual Studio 2008 Standard Edition and higher, Visual C# 2008 Express Edition, and Visual Basic 2008 Express Edition.  The following logic will cause installation to block if none of these Visual Studio editions or versions are installed, but will allow install to proceed if at least one of them is installed (and in that case, it will rely on the component conditions described above to only integrate into Visual Studio versions/editions that are actually installed):

    <CustomAction Id="CA_BlockIfVSIsNotInstalled" Error="!(loc.LaunchCondition_MissingVS)" />

    <InstallExecuteSequence>
      <Custom Action="CA_BlockIfVSIsNotInstalled" Before="CostInitialize">(NOT VS2005_ROOT_FOLDER OR NOT VS2005DEVENV) AND NOT VCSHARP2005EXPRESS_IDE AND NOT VB2005EXPRESS_IDE AND (NOT VS90_ROOT_FOLDER OR NOT VS90DEVENV) AND NOT VCSHARP90EXPRESS_IDE AND NOT VB90EXPRESS_IDE AND NOT Installed</Custom>
    </InstallExecuteSequence>

    <InstallUISequence>
      <Custom Action="CA_BlockIfVSIsNotInstalled" Before="CostInitialize">(NOT VS2005_ROOT_FOLDER OR NOT VS2005DEVENV) AND NOT VCSHARP2005EXPRESS_IDE AND NOT VB2005EXPRESS_IDE AND (NOT VS90_ROOT_FOLDER OR NOT VS90DEVENV) AND NOT VCSHARP90EXPRESS_IDE AND NOT VB90EXPRESS_IDE AND NOT Installed</Custom>
    </InstallUISequence>

    The custom action is included in both the InstallExecuteSequence and the InstallUISequence so that the installation block will occur if the user runs the project template installer in UI mode or in silent mode.

    Provide progress UI strings that will be displayed during installation

    The Visual Studio custom actions that register new project templates can take a while to run, especially if the user has a lot of Visual Studio add-ins, packages and templates on their system.  To help improve the installation experience, I recommend defining strings that will appear in the progress UI while the Visual Studio registration custom actions are running in your project template installer.

    In the example I created, the following ProgressText entries will provide descriptive text for each of the Visual Studio 2005 and Visual Studio 2008 registration custom actions.  Note that the Action names in these entries must match the names of the built-in WiX v3.0 custom actions that were imported earlier in this blog post or the progress text will not appear during installation.

    <UI>
      <ProgressText Action="VS2005Setup" Template="[1]">!(loc.Devenv_Setup_VS2005_Description)</ProgressText>
      <ProgressText Action="VCSHARP2005Setup" Template="[1]">!(loc.Devenv_Setup_VCS2005_Description)</ProgressText>
      <ProgressText Action="VB2005Setup" Template="[1]">!(loc.Devenv_Setup_VB2005_Description)</ProgressText>
      <ProgressText Action="VS90Setup" Template="[1]">!(loc.Devenv_Setup_VS2008_Description)</ProgressText>
      <ProgressText Action="VCSHARP90Setup" Template="[1]">!(loc.Devenv_Setup_VCS2008_Description)</ProgressText>
      <ProgressText Action="VB90Setup" Template="[1]">!(loc.Devenv_Setup_VB2008_Description)</ProgressText>
    </UI>

    Add upgrade logic for future versions of the installer

    This step is something I tend to add to all installers I create and is not specific to Visual Studio project template installers.  I typically use steps like the ones in this blog post to add logic to enable Windows Installer major upgrades.  This gives you more flexibility in case you decide to release a new version of your installer in the future and want it to replace older versions.

  • Aaron Stebner's WebLog

    Links to download Visual Studio 2010 and .NET Framework 4.0 beta 1

    • 9 Comments

    As Soma announced on his blog earlier this week, Visual Studio 2010 beta 1 and the .NET Framework 4.0 beta 1 have shipped.  You can check out this MSDN page and this post on Jason Zander’s blog for information about what is new in VS 2010.  Also, here are links to the various versions of Visual Studio 2010 beta 1 and the .NET Framework 4.0 beta 1 that you can use to download and try out the beta:

    .NET Framework 4.0 beta 1 downloads

    Visual Studio 2010 beta 1 downloads

    Visual Studio 2010 Team Foundation Server beta 1 downloads

    Visual Studio 2010 SDK beta 1 downloads

    Here are a few useful links in case you run into issues while installing or using Visual Studio 2010 beta 1 and the .NET Framework 4.0 beta 1:

  • Aaron Stebner's WebLog

    Media Center SDK for Windows 7 release candidate now available for public download

    • 5 Comments

    I just noticed this item on Charlie Owen's blog and wanted to link to it here as well.  There is now a public download available for the Windows Media Center SDK for the Windows 7 release candidate.  Here are some useful links:

  • Aaron Stebner's WebLog

    Links to introductory information about XNA Game Studio 3.1 Avatar APIs

    • 0 Comments

    My colleague Dean Johnson has posted a couple of items on his blog that I wanted to link to here to help raise visibility.  Dean is the primary developer for the Xbox LIVE Avatar APIs that are going to be a part of the upcoming XNA Game Studio 3.1 release, and he has started posting more details on his blog about how these APIs are going to work and what features that they will support.  Here are links to the posts he’s written so far:

    I encourage you to take a look at Dean’s blog posts for some introductory information about the upcoming Avatar APIs in XNA Game Studio 3.1, and also to keep an eye on his blog in the future for additional details.

  • Aaron Stebner's WebLog

    Links to GDC 2009 XNA Game Studio Developer Day session content

    • 0 Comments

    The PowerPoint slides and the audio recordings for the sessions that were presented at the XNA Game Studio Developer Day at GDC 2009 are now available for download.  Here are links to the download pages and brief descriptions of each session as they are described on the download pages:

    XNA Game Studio Program Overview

    XNA Game Studio has come a long way from XNA Game Studio Express 1.0. Learn about the new features in XNA Game Studio 3.0 and how to publish your game with the XNA Community Games publishing program. We are also unveiling the XNA Game Studio XDK Extensions, a new SDK that enables Xbox LIVE Arcade and retail game development with the XNA Framework on the Xbox 360.

    Analyzing Performance Shortfalls in XNA Game Studio Titles

    Your XNA Game Studio game doesn’t run as well as you expected, and you have no idea why. The first step towards fixing your title is to first understand your title: how it allocates memory, and how it uses the CPU and GPU. This talk demonstrates several of the tools and techniques available to XNA Game Studio developers to analyze their title’s performance shortfalls.

    PIX and XNA Game Studio: Diagnosing Performance Problems

    For years, professional game developers using the DirectX and Xbox 360 Software Development Kits have enjoyed the finest purpose-built performance analysis tools ever created for game development. The good news for game XNA Game Studio developers is that these same tools can be used to enhance their titles using Windows and the XNA Game Studio XDK Extensions. This presentation will explore how to use PIX for Windows and PIX for Xbox 360 to profile and interpret performance issues in XNA Game Studio titles.

    Faster: How to Improve XNA Game Studio Title Performance

    XNA Game Studio provides access to the powerful Xbox 360 console, with multiple CPUs, a complex GPU, and plenty of memory and storage space. Despite all of this power, your title may run slower than expected. This talk will examine several common causes of performance problems and how to address each of them.

    Networking, Traffic Jams, and Schrodinger’s Cat

    The XNA Framework networking API makes it easy to join a session and exchange data packets. But what exactly should you put in those packets? This talk explains how to overcome the challenges posed by limited bandwidth (if you send too much data, or fail to properly compress it, your game could end up even slower than my morning commute) and delivery latency (when packets arrive late, you must use prediction algorithms to smooth things out, creating a strange quantum world where each object has more than one state being simulated in parallel).

    XNA Game Studio XDK Extensions, Certification, and You

    The Holy Grail of XNA Game Studio game development is cost savings and shorter development times over that of large-budget native titles. A significant source of development cost for small developers can come from the time and effort necessary to polish a title for certification and release. This talk will show how the XNA Game Studio XDK Extensions reduce the time necessary to deliver a certifiable, polished title for mainstream release.

  • Aaron Stebner's WebLog

    Possible workaround for RGB9RAST install failure when deploying the .NET Framework 3.0 or 3.5

    • 6 Comments

    I have heard from a few folks recently (such as this blog comment and this forum post) who have run into troubles installing the RGB9RAST component that is a prerequisite for the .NET Framework 3.0, 3.0 SP1, 3.5 and 3.5 SP1 on Windows XP and Windows Server 2003 operating systems.  There is a specific issue in the RGB9RAST .msi that can cause it to fail in some specific conditions, and I wanted to describe how to diagnose and work around this issue in case anyone else runs into a similar error in the future.

    How to diagnose this issue

    If you are encountering this particular RGB9RAST installation issue, you will see an error message like the following by searching for the string return value 3 in the verbose .msi log file for the RGB9RAST component (located at %temp%\dd_rgb9rast*.txt):

    MSI (s) (6C:D0) [10:41:11:075]: Product: RGB9RAST -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2103. The arguments are: 26, ,

    This type of error can occur during .NET Framework 3.0, 3.0 SP1, 3.5 and 3.5 SP1 setup on Windows XP and Windows Server 2003.  Starting with Windows Vista, the RGB9RAST components are available as a part of the OS, and so the RGB9RAST .msi does not need to be installed on Vista or higher and this error will not be seen there.

    How to work around this issue

    If you encounter the above error while attempting to install the RGB9RAST .msi as a part of .NET Framework 3.0, 3.0 SP1, 3.5 or 3.5 SP1 setup on Windows XP or Windows Server 2003, then I suggest trying to manually install the RGBRAST9 .msi with the following command line syntax before running .NET Framework setup:

    msiexec /i RGB9RAST_x86.msi /qn ALLUSERS=1 REBOOT=ReallySuppress

    After you install the RGB9RAST .msi manually, you can run .NET Framework setup and it will detect that the system already has RGB9RAST installed and it will skip attempting to install it and proceed to install the remaining .NET Framework components that are needed on your system.

    Note – you can use the instructions in the .NET Framework 3.0 and 3.5 deployment guides to download the .NET Framework setup package and extract the RGB9RAST .msi needed for the above command line.  Here are the locations of the deployment guides:

    Root cause of this issue

    The RGB9RAST .msi does not set the ALLUSERS property by default.  That can cause problems when deploying the .NET Framework 3.0 or 3.5 from some types of deployment software, particularly deployment software that does not run in the context of a logged in user.  Specifically passing in ALLUSERS=1 on the command line when deploying the RGBRAST .msi will force it to install as a per-machine .msi, which is the appropriate way to install this .msi because the payload it installs goes to a per-machine location.

Page 1 of 1 (7 items)