Aaron Stebner's WebLog

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

September, 2008

  • Aaron Stebner's WebLog

    Link to more details about Zune game development and memory considerations in XNA Game Studio 3.0

    • 0 Comments

    Nazeeh, a colleague of mine, has posted a great article on his blog that I wanted to link to here.  He provides an in-depth introduction to Zune game development with XNA Game Studio 3.0, with a particular focus on optimizing the game memory footprint to fit within the 16 megabyte limit that is enforced for XNA Framework-based Zune games.

    You can find the post at http://www.nazspace.com/wp/2008/09/30/understanding-zune-development/, and it includes the following topics:

    • Understanding the Zune device and the limitations it presents for your games (240x320 screen resolution, 2 gigabytes of game data, 16 megabytes of memory at runtime)
    • Optimizing and reusing textures
    • Minimizing the footprint of audio files used in your games
    • What happens under the hood in an XNA Framework game on the Zune
    • Using the XNA Framework Remote Performance Monitor (RPM) to debug Zune memory issues

    I encourage you to check out this post if you are developing XNA Framework-based games for the Zune or are considering getting started with Zune game development.

  • Aaron Stebner's WebLog

    Upgrading XNA Game Studio projects for use in the XNA Game Studio 3.0 beta

    • 4 Comments

    One of the new features in the XNA Game Studio 3.0 beta is an automated process to upgrade your XNA Game Studio 2.0 projects to the format used by XNA Game Studio 3.0.

    There are a few different upgrade scenarios that you can end up in, depending on what format your original project files are in.  In this post, I will summarize each of them and explain what is needed in order to get up and running in the XNA Game Studio 3.0 beta.

    XNA Game Studio Express 1.0 and 1.0 Refresh projects

    1.0 and 1.0 refresh projects are Visual Studio 2005 projects behind the scenes.  This means that attempting to open them in Visual Studio 2008 and XNA Game Studio 3.0 will trigger the built-in Visual Studio 2008 conversion wizard.  However, the XNA Game Studio 3.0 product does not include the necessary logic to automatically upgrade these projects to 3.0 format.  That means that if you use the built-in Visual Studio 2008 conversion wizard, your project will be converted from VS 2005 to VS 2008 format, but it will not work as expected with XNA Game Studio 3.0.

    The options for upgrading 1.0 and 1.0 refresh projects are outlined in item 1.2.3 in the XNA Game Studio 3.0 beta readme.  To summarize that item, you can do one of the following:

    1. Create a new game project in XNA Game Studio 3.0, then import your code and content files
    2. Use the XNA Game Studio 2.0 upgrade wizard to convert your 1.0 or 1.0 refresh project to 2.0, then open the converted 2.0 project in Visual Studio 2008 and XNA Game Studio 3.0

    My colleague Stephen posted a very helpful set of steps for option 1 in this post on the Creators Club forums.  Here is a summary of those steps:

    1. Create a new game project in the XNA Game Studio 3.0 beta
    2. Delete the code files created by default by the new project (Game1.cs, Program.cs)
    3. Right-click on the new project in the VS Solution Explorer and choose Add | Existing Item...
    4. Browse to the old project directory and select all the code files (*.cs). This will copy the old files into the new project. If you have your code in sub-folders, add new folders to the new project first, then right-click and add files to the folder node.
    5. Right-click on the Content node under the new project, and choose Add | Existing Item...
    6. Browse to the old project directory and select all the content files (*.x, *.jpg, etc). This will copy the old files into the new project. Note that doing this will place all the build content into a subdirectory called Content. You should modify your content loading code accordingly. The RootDirectory property on ContentManager will make this easy.
    7. If you had additional references for the Content Pipeline, you now add those to the References node in the Content project under your new project. The Content node is actually a nested project, which only builds content with the Content Pipeline. This was introduced in XNA Game Studio 2.0.
    8. Fix up your code to match the API changes that have occurred between 1.0 to 3.0. The biggest changes occurred between 1.0 and 2.0. There is an MSDN topic named XNA Framework Changes in XNA Game Studio 2.0 that will help here.
    9. You may need to fix up the Content Pipeline properties because a few things have changed since 1.0.

    XNA Game Studio 2.0 projects

    2.0 projects are Visual Studio 2005 projects behind the scenes.  When you open them in Visual Studio 2008 and XNA Game Studio 3.0, the built-in Visual Studio 2008 conversion wizard will run.  XNA Game Studio 3.0 extends this conversion wizard to make the necessary changes to 2.0 project files so they will open, build and run correctly with XNA Game Studio 3.0.  The conversion process does not change any of the code in any of your projects though, so if there are any behavior changes in XNA Framework APIs between XNA Game Studio 2.0 and 3.0 that affect your scenarios, you will need to update the code yourself as needed.

    XNA Game Studio 3.0 CTP projects

    3.0 CTP projects are Visual Studio 2008 projects behind the scenes.  When you open them in Visual Studio 2008, the conversion wizard does not run because Visual Studio does not detect that any upgrades are needed.  As a result, there is not an opportunity for XNA Game Studio 3.0 to automatically upgrade old CTP projects when they are opened in the beta.  In addition, there is not any metadata in a 3.0 CTP project to guarantee that it was created in the CTP.  Instead, there is logic in the build process to display an error like the following if you attempt to build a CTP project in the beta:

    The project file '<projectname>' appears to have been created with XNA Game Studio 3.0 CTP. For instructions on how to upgrade this project to work with the current version, copy and paste this link into your browser: http://go.microsoft.com/fwlink/?LinkId=121512.

    This link redirects to the XNA Game Studio 3.0 beta readme, and the steps required to update your 3.0 CTP projects to 3.0 beta format are listed in item 1.2.1 there.  Here is a summary of those steps (I have modified them slightly from the ones listed in the readme because the ones in the readme only work in Visual Studio 2008 but not in Visual C# 2008 Express Edition):

    1. Open <projectname>.csproj in a text editor such as Notepad.
    2. Scroll down to the bottom of the .csproj file and locate the following three <Import.../> elements.

      <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
      <Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\v3.0\Microsoft.Xna.GameStudio.Common.targets" />
      <Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\v3.0\Microsoft.Xna.GameStudio.NestedContent.targets" />

    3. Replace these with the following two <Import.../> elements. Note that the first element is the same.

      <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
      <Import Project="$(MSBuildExtensionsPath)\Microsoft\XNA Game Studio\Microsoft.Xna.GameStudio.targets" />

    4. Save <projectname>.csproj file.
    5. Open <projectname>.csproj in Visual C# 2008 Express Edition or Visual Studio 2008 in order to use it with the XNA Game Studio 3.0 beta.

    <update date="10/1/2008"> Clarified the steps to update a CTP project - they were originally using steps that only work in Visual Studio 2008 but not in Visual C# 2008 Express Edition. </update>

     

  • Aaron Stebner's WebLog

    Possible problem adding a Zune in Device Center on a 64-bit OS using the XNA Game Studio 3.0 beta

    • 0 Comments

    Description of this issue

    We received a bug report last week from a customer who was unable to add a Zune to the XNA Game Studio Device Center after installing the XNA Game Studio 3.0 beta.  The customer was running a 64-bit version of Windows Vista on the system that this issue appeared on.  When clicking the Add Device button in the Device Center and selecting Zune, they received an error stating that they needed to install the Zune software on their computer, even though they had already visited the Zune download page and installed the Zune 3.0 software and the Zune 3.0 firmware on their Zune.

    How to work around this issue

    After some further investigation, we discovered that this customer had some incorrect information in their registry that was causing the Device Center to incorrectly report that the Zune software was not installed.  In order to allow this customer to add a Zune in their Device Center, we had them delete the following value from their registry after installing the 64-bit version of the Zune 3.0 software:

    [HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Zune]
    CurrentVersion

    After removing the above registry value, the customer was able to run the XNA Game Studio Device Center, add their Zune device, and deploy and debug their Zune applications using the XNA Game Studio 3.0 beta.

    Root cause of this issue

    In the XNA Game Studio 3.0 beta, on a 64-bit OS, the Device Center has logic to look in the 32-bit registry before looking in the 64-bit registry to determine whether or not the Zune software is installed.  It first checks the 32-bit registry value at this location:

    [HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Zune]
    CurrentVersion

    If this CurrentVersion value exists, it will check to see if the version value is 3.0 or higher.  On the customer's system where this error was seen, the 32-bit version of the CurrentVersion value was set to 0.0.0.0 for some reason, which caused the error to be reported because this version value is less than 3.0.

    If the 32-bit CurrentVersion value does not exist, it will check the 64-bit registry value at this location:

    [HKEY_LOCAL_MACHINE\Software\Microsoft\Zune]
    CurrentVersion

    The 64-bit version of the Zune software only sets the 64-bit registry value for CurrentVersion, so we will be fixing the Device Center before the final release of XNA Game Studio 3.0 so invalid values in the 32-bit registry will not block you from adding a Zune on a 64-bit OS.

  • Aaron Stebner's WebLog

    Link to a survey about .NET Framework deployment experiences

    • 0 Comments

    Peter Marcu has posted a survey on his blog that I wanted to link to here in order to try to help him get more responses.  He's looking for data to help improve the deployment experience in future versions of the .NET Framework redistributable.

    If you are a developer working on the deployment of applications that require the .NET Framework, I encourage you to check out his blog post at http://blogs.msdn.com/pmarcu/archive/2008/09/20/do-you-deploy-a-managed-app.aspx and post comments there or send him an email to share your experiences and suggestions for improvements.

  • Aaron Stebner's WebLog

    ClickOnce publishing integration and improved Windows game deployment in XNA Game Studio 3.0

    • 18 Comments

    Important note: The information in this blog post is specific to the XNA Game Studio 3.0 beta.  There have been some changes in the final release of XNA Game Studio 3.0.  For more information about Windows game publishing using the final release of XNA Game Studio 3.0, please refer to the updated blog post at http://blogs.msdn.com/astebner/archive/2008/10/31/9027445.aspx. 

    As previously noted, the XNA Game Studio 3.0 beta has been released.  One of the features that we added in the beta is ClickOnce publishing support for XNA Framework-based Windows games.  I wanted to go over the behind-the-scenes details for this feature and explain how to configure and use it in a Windows game.

    What is ClickOnce and why hasn't it worked in the past for games?

    ClickOnce is an application deployment technology that can be used to publish applications to Web servers or network file shares for simplified installation scenarios.  ClickOnce features have been available in Visual Studio for a couple of versions, but have not worked well with XNA Game Studio for a couple of reasons:

    1. In XNA Game Studio 2.0, the output of nested content projects was not included in the ClickOnce publishing output when publishing in Visual Studio.  There are some advanced steps that can be used to work around this, but they require in-depth ClickOnce knowledge and also require running publishing tools outside of Visual Studio (such as mage.exe and mageui.exe).
    2. Prerequisites needed to run XNA Framework-based games on computers that do not have XNA Game Studio installed have not been integrated into the Visual Studio publishing process in the past, and the requirements for manually creating installers have been poorly (or worse - inaccurately) documented.

    Changes made in the XNA Game Studio 3.0 beta for ClickOnce scenarios

    We have addressed the above issues in the XNA Game Studio 3.0 beta by doing the following:

    1. Updating our build steps to properly include nested content project output in the ClickOnce publishing output for a Windows game.
    2. Creating a Visual Studio bootstrapper package for the XNA Framework Redistributable 3.0 that can be included as a prerequisite for ClickOnce-based installers and/or Windows Installer-based installers.
    3. Configuring XNA Game Studio 3.0 Windows game projects to have a dependency on the XNA Framework Redistributable 3.0 bootstrapper package so that this prerequisite will be included by default when publishing Windows games using ClickOnce.
    4. Moving the DirectX runtime files required for XNA Framework-based games into the XNA Framework redistributable so they do not need to be installed as a separate step anymore.

    How to publish an XNA Game Studio 3.0 Windows game

    There are a couple of ways to access publishing functionality in Visual C# 2008 Express Edition or Visual Studio 2008.  The following steps will allow you to publish using the default settings for prerequisite packages:

    1. Open Visual C# 2008 Express or Visual Studio 2008.
    2. Create a new XNA Game Studio 3.0 Windows game project.
    3. Click on the Build menu and choose Publish <game> - this will launch the Visual Studio Publish Wizard.
    4. Specify the publishing output location.
    5. Choose the installation mechanism to offer to your users - install from the Web, install from a UNC path or file share, or install from a CD/DVD.
    6. Choose whether or not to enable automatic updates for your game.
    7. Click Finish to publish (which will trigger a build automatically if your build output is out of date).

    ClickOnce publishing output

    The above steps will produce a publishing output folder that contains the following:

    • setup.exe - this is the setup executable for your game, and it contains logic to install prerequisites and then trigger ClickOnce to deploy your game payload
    • <game>.application - this is the ClickOnce deployment manifest for your game
    • Application Files folder that contains your game payload
    • xnafxredist30 folder that contains the XNA Framework Redistributable 3.0 MSI

    The above steps will automatically configure your game to include the .NET Framework 3.5 and the XNA Framework Redistributable 3.0 as prerequisites.  It will use the default deployment settings for each of these prerequisites.  For the .NET Framework 3.5, this means that setup.exe will detect whether or not the user's system needs the .NET Framework 3.5 and will download and install it if it is missing.  For the XNA Framework Redistributable 3.0, it will deliver the MSI as payload in a sub-folder next to setup.exe (in the beta only).

    In the XNA Game Studio 3.0 beta, you will notice that publishing a Windows game will result in a warning in the error list that states the following:

    No 'HomeSite' attribute has been provided for 'Microsoft XNA Framework Redistributable 3.0', so the package will be published to the same location as the bootstrapper.

    We did not specify a HomeSite value in the beta because we did not post the XNA Framework Redistributable 3.0 MSI as a separate download.  In the final release of XNA Game Studio 3.0, we will post the XNA Framework Redistributable 3.0 MSI as a separate download, and we will update this bootstrapper package to specify a valid HomeSite value.  That will cause the default publishing behavior to be to cause setup.exe to detect whether or not the user's system needs the XNA Framework Redistributable 3.0 and to download and install it if it is missing (like the default behavior for the .NET Framework 3.5).

    How to configure non-default ClickOnce publishing options

    In order to change the default publishing behavior for XNA Game Studio 3.0 Windows game, you can use the following steps:

    1. Right-click on your Windows game project in the Visual Studio Solution Explorer and choose Properties.
    2. In the property pages, select the Publish tab.
    3. Use the Application Files... button to exclude payload from your publishing output.
    4. Use the Prerequisites... button to add/remove prerequisite packages or to change how they are packaged (download from the manufacturer's web site, download from the same location as the application, package in a directory along with the game).
    5. Use the Updates... button to enable automatic update checking and configure the update details.
    6. Use the Options... button to configure other advanced ClickOnce options.
    7. Use the Publish Wizard... button to invoke the publishing wizard (the same one that appears if you click on the Build menu and choose Publish <game> in the previous set of steps.
    8. Use the Publish Now button to publish using the default publishing settings without stepping through the wizard.

    Notes about installing Windows games using ClickOnce

    After publishing your game, you can install it on another system by running setup.exe or by running <game>.application (if the target system already has the .NET Framework 2.0 or higher, it will know how to handle the .application file extension).  Any missing prerequisites will be installed, and then your game will be deployed.  Here are a few key notes about this deployment process:

    • ClickOnce applications are deployed as per-user application to a randomly-generated folder under the currently logged in user's %LOCALAPPDATA% folder.  This folder is chosen automatically by ClickOnce, and you do not have any control over this location in the publishing process.
    • ClickOnce will create a Start menu shortcut for your game.
    • ClickOnce will create an Add/Remove Programs entry so that the user can uninstall the game later.
    • If you choose to include automatic updates for your game, ClickOnce will check for new versions of your game each time the user launches it, and will deploy new versions if they are available.

    Using a setup/deployment project to create a game installer

    Visual Studio Professional Edition and higher offers the ability to create MSI-based installers in addition to ClickOnce packages.  Both of these deployment solutions use the same bootstrapper packages for installing prerequisites.  This means you can also use a setup/deployment project in Visual Studio 2008 Professional Edition and higher to create an MSI to install your game, and then include the XNA Framework Redistributable 3.0 as a prerequisite.

    It is important to note that XNA Game Studio 3.0 does not support automatically adding game or content project output to the setup project (which is normally done by right-clicking the setup project, choosing Add | Project output... and selecting the primary output of the desired project in the Add Project Output Group dialog).  As a result, you will have to manually add the binary files and content files that you want to install as a part of your game to your setup project one-by-one if you choose this option.

    Here are steps that you can use to accomplish this:

    1. Open Visual Studio 2008 Professional or higher (setup/deployment projects are not available in the Standard or Express Editions).
    2. Create a new XNA Game Studio 3.0 Windows game project.
    3. Right-click on the solution in the Visual Studio Solution Explorer and choose Add | New Project...
    4. Go to Other Project Types | Setup and Deployment and add a Setup Project.
    5. Use the File System designer to populate the project with the payload of your game (content plus game binaries).  To do this, right-click on your setup project and choose View | File System.  Then create folders and add files in the desired locations.
    6. Right-click on your setup project in the Solution Explorer and choose Properties.
    7. Change the configuration drop down if you want the changes to affect both debug and release builds.
    8. Click on the Prerequisites... button to bring up the Prerequisites selection dialog.
    9. Scroll to the bottom and check the item named Microsoft XNA Framework Redistributable 3.0, then click OK.
    10. Build your solution.

    After a build, your setup project's output directory will contain the following:

    • setup.exe - this is the setup executable for your game, and it contains logic to install prerequisites and then trigger the installation of your MSI
    • <game>.msi - this is the Windows Installer MSI file that contains your game payload
    • xnafxredist30 folder that contains the XNA Framework Redistributable 3.0 MSI

    In the XNA Game Studio 3.0 beta, you will see the same warning about the HomeSite attribute as described above in the ClickOnce publishing steps.  This is because the same underlying bootstrapper package is used by ClickOnce and setup/deployment projects.  In the final release of XNA Game Studio 3.0, it will be possible to enable download-and-install-on-demand scenarios for the XNA Framework Redistributable 3.0.

    Important note about the contents of the XNA Framework Redistributable 3.0

    The above information describes how to create an installer for an XNA Framework-based Windows game.  There are a couple of key scenarios that are not currently possible when deploying a Windows game to a system in this way because the necessary functionality is only installed by XNA Game Studio, not by the XNA Framework Redistributable:

    • The Microsoft Games for Windows - LIVE Redistributable package is installed during XNA Game Studio setup, but it is not available for redistribution as a part of a game installer.  A Windows game that attempts to use networking functionality provided by this package on a system without XNA Game Studio installed will encounter a GamerServicesNotAvailableException.
    • The Content Pipeline Build Runtime is installed during XNA Game Studio setup, but it is not included in the XNA Framework Redistributable.  Building content at run time (which could be used for things like level editors and game modding engines) is only supported when XNA Game Studio has been installed on the Windows-based development computer.

    Behind the scenes details if you are interested

    If you are interested in more details, you can see the data files for the XNA Framework Redistributable 3.0 bootstrapper package by looking at the folder %ProgramFiles%\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages\XnaFxRedist30 on a system with XNA Game Studio 3.0 installed.  We created this bootstrapper package by using the steps in this MSDN document about creating custom bootstrapper packages.

    Summary

    Windows game packaging and deployment have been consistent pain points since the first version of XNA Game Studio Express.  Hopefully the features that we've added in the XNA Game Studio 3.0 beta will end up being useful in making this process simpler and less error prone.  If you are creating Windows games using XNA Game Studio, I encourage you to try out these features in the 3.0 beta and let us know if you run into any troubles using these features and/or have any suggestions for further improvements by posting on the forums and/or reporting bugs on the Connect site.

    <update date="9/30/2008"> Clarified that adding project output from a game project or a content project into a setup/deployment project will not work in XNA Game Studio 3.0.  Instead, if you plan to use a setup/deployment project, you have to manually add the game binaries and content files to the setu project one-by-one. </update>

    <update date="10/20/2008"> Added a note about networking and content building scenarios that are supported on systems that have XNA Game Studio installed, but not on systems that only have the XNA Framework Redistributable installed. </update>

    <update date="11/3/2008"> Added a caveat that this information is only applicable in the XNA Game Studio 3.0 beta, and added a link to the updated blog post that I wrote about Windows game deployment in the final release of XNA Game Studio 3.0. </update>

     

  • Aaron Stebner's WebLog

    Links to posts with more details about some new features in the XNA Game Studio 3.0 beta

    • 0 Comments

    With the release of the XNA Game Studio 3.0 beta, some of my colleagues have started posting information on their blogs about some of the new features available in the 3.0 beta.  Here are links and brief summaries for the posts that have been written so far:

    <update date="9/20/2008"> Added links to a few new posts that team members have written over the past couple of days. </update>

     

  • Aaron Stebner's WebLog

    XNA Game Studio 3.0 beta is now available for download

    • 2 Comments

    As announced today on this post on the XNA team blog, the XNA Game Studio 3.0 beta is now available for you to download and try out.

    Getting started

    Here are some links with information about how to download and get started using the XNA Game Studio 3.0 beta:

    If you previously had the XNA Game Studio 3.0 CTP installed

    If you previously had the XNA Game Studio 3.0 CTP installed, there are a few things you will need to keep in mind:

    • You must uninstall the item named Microsoft XNA Game Studio 3.0 (CTP) from Add/Remove Programs prior to installing the XNA Game Studio 3.0 beta.
    • Game projects created in the CTP must be manually updated to work in the beta.  If you try to compile a CTP project in the beta, you will get an error that contains a link to the beta readme.  There are instructions in the readme that explain how to update your CTP projects.
    • Games compiled and deployed in the CTP must be recompiled and redeployed using the beta.

    If you encounter setup failures in the XNA Game Studio 3.0 beta

    If you run into setup failures while installing the XNA Game Studio 3.0 beta, it can help to look at the log files created by XNA Game Studio 3.0 setup.  They are located at %temp%\XNA Game Studio 3.0 Setup\Logs.

    Limitations of the XNA Game Studio 3.0 beta

    Here are some key limitations to keep in mind when getting started installing and using the XNA Game Studio 3.0 beta:

    • You can create and compile Xbox 360 projects in the beta, but you cannot deploy and run them on an Xbox 360, even if you have a Creators Club membership.  This functionality will be available in the final release of XNA Game Studio 3.0 though.
    • Deploying and playing Zune games in the beta requires that your Zune device has the recently released 3.0 firmware installed.  You can find more information about getting the 3.0 firmware at http://www.zune.net/.
    • As described in this blog post, once you install the Zune 3.0 firmware, you will no longer be able to use the XNA Game Studio 3.0 CTP to create and deploy games to your Zune, and you will no longer be able to run games already on the device that were created with the CTP.  There are instructions in that blog post for how to delete old CTP games from your device.
    • XNA Game Studio 3.0 only supports Visual C# 2008 Express Edition and VS 2008.  It does not support Visual C# 2005 Express Edition or VS 2005 like previous versions of XNA Game Studio.  You must have a VS 2008 edition installed on your computer before you will be able to install XNA Game Studio 3.0.  You can install VS 2005 and VS 2008 side-by-side on the same computer with no problems though, so there is no need to uninstall VS 2005 or any previous versions of XNA Game Studio in order to try out the XNA Game Studio 3.0 CTP.
  • Aaron Stebner's WebLog

    XNA Game Studio 3.0 beta is coming soon

    • 0 Comments

    As noted in this post on the XNA team blog earlier today, the beta version of XNA Game Studio 3.0 is coming next week.  The blog post contains a list of key new and changed features between the XNA Game Studio 3.0 CTP that was released back in May and the upcoming beta.  Here is a summary of the features:

    Zune-specific features

    • Support for the upcoming Zune 3.0 firmware - note that the XNA Game Studio 3.0 CTP will not be compatible with the 3.0 firmware.  My colleague Michael Klucher posted a summary of this issue on his blog, including steps to remove 3.0 CTP games from your Zune since they will no longer work with the 3.0 firmware
    • Zune deployment from 64-bit OS's
    • Remote Performance Monitor will now work for Zune

    Xbox 360-specific features

    • Xbox 360 project templates are available - however, you cannot deploy games to the Xbox 360 with the beta
    • Big button pad support

    XNA Framework and Visual Studio features

    • Media enumeration and playback on Windows and Xbox 360 (parity with the Zune APIs that were available in the CTP)
    • Simple sound effects on Windows and Xbox 360
    • Rich presence, invites and join session in progress
    • Content compression
    • FBX importer improvements
    • Support for C# 3.0 features in Xbox 360 and Zune games (this was already available for Windows in the CTP)
    • Screenshots of games while they are running on a Zune
    • ClickOnce deployment for Windows games
    • Project upgrade wizard to automatically upgrade XNA Game Studio 2.0 games
    • Multiple content projects
    • Cross-platform project synchronization

    I'm looking forward to getting feedback on the XNA Game Studio 3.0 beta once it is available next week.  I'm planning to post some more detailed information about some of the above features that I worked directly on for this beta, so stay tuned.

    As always, bugs and feature suggestions for XNA Game Studio and the XNA Framework can be reported via the Microsoft Connect site.  Our team takes these bug reports very seriously, so I definitely encourage you to report issues there.

  • Aaron Stebner's WebLog

    Possible cause of Windows Vista and Windows Server 2008 OS update failures with error code 0x8000ffff

    • 3 Comments

    Recently, I was helping a colleague troubleshoot an installation error in the .NET Framework 3.5 SP1 on Windows Server 2008.  I wanted to describe the specific issue, and also explain how we narrowed down the issue because I think these troubleshooting techniques could be useful for investigating other types of .NET Framework 3.5 or 3.5 SP1 installation failures on Windows Vista or Windows Server 2008.

    How to narrow down this issue

    In this scenario, the .NET Framework 2.0 SP2 component was failing to install during .NET Framework 3.5 SP1 setup.  We started by looking at the log file named %temp%\dd_dotnetfx35install.txt, and found the following error:

    [08/08/08,11:11:11] Microsoft .NET Framework 2.0SP1 (CBS): CBSComponent Action: CreateProcess launched with cmd line : C:\Windows\system32\WUSA.exe "C:\Windows\system32\WUSA.exe" "c:\e3e05fbe88ad4e54ff9203e6\wcu\dotNetFramework\dotnetmsp\x86\NetFX2.0-KB948609-v6001-x86.msu" /quiet /norestart
    [08/08/08,11:11:11] Microsoft .NET Framework 2.0SP1 (CBS): C:\Windows\system32\WUSA.exe exited with return value 2147549183
    [08/08/08,11:11:11] InstallReturnValue: GFN_MID NET Framework 2.0SP1 (CBS), 0x8000ffff

    Even though this log says that the component is the .NET Framework 2.0 SP1, the package that was actually failing in this case was the .NET Framework 2.0 SP2.  We know this because the package being installed is named NetFX2.0-KB948609-v6001-x86.msu (which is the .NET Framework 2.0 SP2 package), and because the .NET Framework 3.5 SP1 installs the .NET Framework 2.0 SP2 and 3.0 SP2 as prerequisites (not 2.0 SP1 and 3.0 SP1).  The package ID in this log file was not updated between the .NET Framework 3.5 and 3.5 SP1.

    Since the package that was failing in this case is an OS update package, we continued this investigation by looking at the Windows OS update log file named %windir%\logs\cbs\cbs.log.  We found the following error in that log file:

    2008-08-08 11:11:11, Info                  CBS    WER: Generating failure report for package: Package_for_KB948609~31bf3856ad364e35~x86~~6.0.6001.3053, status: 0x8000ffff, failure source: Resolve, start state: 0, target state: 7
    2008-08-08 11:11:11, Info                  CBS    Exec: Processing complete.  Session: 29949001:229928128, Package: Package_for_KB948609~31bf3856ad364e35~x86~~6.0.6001.3053, hr: 0x8000ffff

    This error information did not help much, but further investigation in cbs.log showed that other non-.NET Framework update packages were also failing with the same 0x8000ffff error code.  Based on that, we were able to determine that this error was a general problem with the OS update installation engine as opposed to a specific .NET Framework setup issue.

    We had some colleagues on the Windows deployment team help us debug this further, and found that there was some kind of problem with the Cryptographic Services on the system, but we did not yet know what.  Eventually, we found some information in the event log on the system that indicated that there were some missing permissions that prevented the Cryptographic Services from being able to access the catalog database.

    How to resolve this issue

    In order to resolve this issue, we had to use the steps described in this blog post in order to grant the BUILTIN\Users group read access to the system drive.

    The Cryptographic Services runs using Network Service credentials, which means that it requires the Users group to have read access to resources that it needs to be able to access when it runs.

    Another possible resolution for 0x8000ffff errors

    I recently found this forum thread that contains some additional suggestions that might be helpful if you run into a 0x8000ffff error while trying to install a Windows Vista or Windows Server 2008 OS update.  If the above suggestion does not work on your system, I'd suggest looking at this forum thread as well.

    General advice for troubleshooting .NET Framework install failures on Windows Vista and Windows Server 2008

    When troubleshooting .NET Framework 3.5 or 3.5 SP1 installation issues on Windows Vista and Windows Server 2008, it is important to remember that some of the failures can be caused by OS update installation engine problems.  I usually use the pattern described above to narrow down this type of issue.  Specifically, I do the following:

    1. Start by opening %temp%\dd_dotnetfx35install.txt and searching for the string errorlog event to narrow down which component of the .NET Framework is failing to install
    2. If you are on Windows Vista or Windows Server 2008, and if the failure is in the Microsoft .NET Framework 2.0SP1 (CBS) or Microsoft .NET Framework 3.0SP1 (CBS) component (or their 64-bit equivalents), then you will typically need to look in %windir%\logs\cbs\cbs.log, %windir%\WindowsUpdate.log and/or the event logs for more in-depth error information because the .NET Framework 2.0 and 3.0 service packs are installed as OS update packages on Windows Vista and Windows Server 2008, and because of that, they will report information into the Windows update installation log files during their installation processes.

    When looking in cbs.log and/or WindowsUpdate.log, it is useful to attempt to match up the time stamps from the dd_dotnetfx35install.txt in order to better correlate log entries.  It is also useful to look for the same error code from other Windows update packages in order to determine if the problem is specific to .NET Framework updates or if it is a more general problem with all Windows updates being installed on the system.

    <update date="3/12/2009"> Added a link to a forum post that can help resolve some types of 0x8000ffff errors. </update>

     

  • Aaron Stebner's WebLog

    Naming an assembly incorrectly when creating an MSI can cause a 1935 error with HRESULT 0x80131047

    • 0 Comments

    Recently, I heard from a customer who was attempting to create an MSI-based installer using WiX v3.0.  They needed to install an assembly to the global assembly cache (GAC) in their installer, but when they attempted to run their MSI, the installation failed.  The verbose MSI log file contained an error message like the following:

    Error 1935. An error occurred during the installation of assembly 'MyAssembly,version="1.0.0.0",culture="neutral",publicKeyToken="################",processorArchitecture="MSIL"'. Please refer to Help and Support for more information. HRESULT: 0x80131047. assembly interface: IAssemblyCacheItem, function: Commit, component: {########-####-####-####-############}

    From the information in corerror.h in the Windows SDK and in the blog post I wrote a while back about error code 1935, the HRESULT value 0x80131047 means "The given assembly name or code-base is invalid."

    The customer tried installing the same assembly manually using gacutil.exe and it worked fine, so this error didn't make much sense initially.

    After examining their WiX authoring and trying some scenarios, I discovered a tricky authoring error that ended up being the cause of this error.  The WiX authoring that led to the error looked like this:

    <Component Id='MyComponent' Guid='PUT-GUID-HERE'>
        <File Id='MyFile'
                Name='MyName'
                DiskId='1'
                Source='MyAssembly.dll'
                Assembly='.net'
                KeyPath='yes' />
    </Component>

    The underlying issue turned out to be that the destination name of the file did not match the assembly identity for this assembly.  Behind the scenes, Windows Installer uses fusion APIs to install assemblies to the GAC, and fusion requires that the file name be the same as the assembly identity.  When the customer was attempting to manually run gacutil.exe on this assembly, they used the source file name (MyAssembly.dll in this case), which did match.  However, the WiX authoring caused the file to be installed with the name MyName, and then when Windows Installer attempted to call fusion APIs to install the assembly from the location the file was installed to, that copy of the file did not have a name that matched the assembly identity, and it resulted in a 1935 error with HRESULT 0x80131047.

    Changing this setup authoring to the following and rebuilding the MSI allowed the installation to succeed:

    <Component Id='MyComponent' Guid='PUT-GUID-HERE'>
        <File Id='MyFile'
                Name='MyAssembly.dll'
                DiskId='1'
                Source='MyAssembly.dll'
                Assembly='.net'
                KeyPath='yes' />
    </Component>

    Since this type of scenario is tricky to debug and it is also possible to catch it up-front when creating the MSI in the first place, I logged this bug on the WiX SourceForge site so that hopefully this will be caught in the WiX build process in the future.  In the meantime, if you are authoring assemblies to be installed to the GAC in WiX, make sure that the destination name being used for each of your assemblies matches the actual assembly identity.

    Update: The WiX bug I logged has been fixed, and you will now receive a warning if you attempt to author an assembly in WiX v3.0 to install to the GAC but provide a destination file name that does not match the assembly identity.  That means that this scenario will no longer be reachable if you're using a recent build of WiX v3.0.

    <update date="3/12/2009">Added a note indicating that the WiX bug I logged a while back has been fixed. </update>

     

  • Aaron Stebner's WebLog

    XNA Game Studio talks from Gamefest 2008 are now available for download

    • 0 Comments

    The audio files for talks given by members of the XNA Community Gaming Platform team at Gamefest 2008 have been posted for download on the Microsoft download center.  If you weren't able to attend Gamefest 2008 or if you'd like to listen to the talks again, I encourage you to download them and check them out.  Here is a complete list of the available talks:

Page 1 of 1 (11 items)