Configuring XNA Game Studio 3.0 projects with custom content processors to work with ClickOnce deployment

  • Article

Since we released XNA Game Studio 3.0, I've heard of a few problems from customers via my blog and the Creators Club forums related to deployment of Windows game projects that include custom content processors.  Most of the problems I've heard of so far involve using ClickOnce to deploy a game, then receiving the following error message when attempting to run the game on another computer that doesn't have XNA Game Studio 3.0 installed:

Unable to install or run the application. The application requires that assembly Microsoft.Xna.Framework.Content.Pipeline be installed in the Global Assembly Cache (GAC) first.

This error is typically caused by including a reference to the custom content processor in the Windows game project even though the processor is only needed at build time.  If the processor is only needed at build time, you only need to include a reference to it in your content project.  Doing this will prevent any dependencies on content pipeline assemblies while running your game.  This is important because the XNA Framework Redistributable 3.0 does not contain content pipeline assemblies, which means that the only way to run a game that requires content pipeline assemblies at runtime (and not just at build time) is to install XNA Game Studio 3.0 on the target system.

I have also heard of one issue where someone fixed the content pipeline assembly reference issue described above, but then ran into an exception stating that the type ContentTypeReader cannot be found when deploying their their game to another computer.  Custom content processors can include several parts - an importer, a processor, a type writer and a type reader.  Of these, the type reader and any types used by your game need to be deployed to the target system along with your game binaries and content.  The importers, processors and type writers are only needed at build time and do not need to be deployed to the target system.

In order to avoid deployment issues, if you have a custom content processor that includes both build time and runtime components, you can split your custom content processor into the following:

  • A content pipeline extension project that includes the importers, processors and type writers.  This project will be used at build time, and needs to be included as a reference in your content project(s) but not your game project(s)
  • A game library project or code files that are included in your game project and includes the type readers and any types used by the game.  If you use a game library project, you need to include it as a reference in your game project(s)

To better understand the content pipeline and the split between build time and runtime components, I'd suggest reading the recent post that Shawn Hargreaves wrote at https://blogs.msdn.com/shawnhar/archive/2008/11/24/content-pipeline-assemblies.aspx.  The post includes the following information:

  • Content pipeline data flow
  • What parts of the content pipeline run at build time on the development PC versus running at game run time on the target device
  • Details about creating custom content processors based on real world scenarios from samples currently available on the Creators Club site