Why does my content rebuild every time?

Why does my content rebuild every time?

  • Comments 6

The XNA Framework Content Pipeline tries to use incremental rebuilds wherever possible. This means if you add a hundred content files, build your project, change just one of those files, then build again, only that specific file needs to be rebuilt.

In a perfect world this would work 100% of the time, but in reality we sometimes rebuild more content than is strictly necessary. Most often this happens if you make a change to a custom processor assembly. The pipeline does not keep track of which assemblies were involved in building which pieces of content, so if any custom assembly changes, all content will be rebuilt. Unwanted rebuilds may also occur when changing project settings, if you have circular project references, or if the Content Pipeline cache file is somehow getting deleted.

If you think your content is rebuilding more often than it should, you can find out why by turning up the MSBuild output verbosity. If you rebuild-all with the Skinned Model sample, the Visual Studio output pane will normally show something like:

    Building dude.fbx -> SkinningSample\bin\x86\Debug\Content\dude.xnb 
    Building head.tga -> SkinningSample\bin\x86\Debug\Content\head_0.xnb 
    Building SkinnedModel.fx -> SkinningSample\bin\x86\Debug\Content\SkinnedModel_0.xnb 
    Building jacket.tga -> SkinningSample\bin\x86\Debug\Content\jacket_0.xnb 
    Building pants.tga -> SkinningSample\bin\x86\Debug\Content\pants_0.xnb 
    Building upBodyC.tga -> SkinningSample\bin\x86\Debug\Content\upBodyC_0.xnb 

Open the Tools / Options menu in Visual Studio. If you are using C# Express, make sure the Show all settings box is checked. Expand Projects and Solutions, select the Build and Run node, and change the MSBuild project build output verbosity setting from Minimal to Normal.

Now when we rebuild-all, the output pane shows:

    Target CoreCompile: 
        Building dude.fbx -> SkinningSample\bin\x86\Debug\Content\dude.xnb 
        Rebuilding because asset is new 
        Importing dude.fbx with Microsoft.Xna.Framework.Content.Pipeline.FbxImporter 
        Serializing obj\x86\Debug\dude_0.xml 
        Processing dude.fbx with SkinnedModelPipeline.SkinnedModelProcessor 
        Compiling SkinningSample\bin\x86\Debug\Content\dude.xnb 
        (etc)

If we make a change to SkinningData.cs, which changes the custom pipeline assembly, the next build will show:

    Target CoreCompile: 
        Rebuilding all content because pipeline assembly SkinnedModelPipeline.dll has changed 
        Building dude.fbx -> SkinningSample\bin\x86\Debug\Content\dude.xnb 
        Importing dude.fbx with Microsoft.Xna.Framework.Content.Pipeline.FbxImporter 
        Serializing obj\x86\Debug\dude_0.xml 
        Processing dude.fbx with SkinnedModelPipeline.SkinnedModelProcessor 
        Compiling SkinningSample\bin\x86\Debug\Content\dude.xnb 
        (etc)

If you find that content keeps rebuilding because assemblies are changing, consider splitting these assembles to separate game logic (which tends to change often) from content data types (which change less often). If your content project can avoid referencing your game logic assembly, it will no longer need to rebuild each time that code changes.

  • On our project, we hit that exact problem, and at a certain point it became very painful because a full content build took more than ten minutes to complete. We solve it by splitting the content into two separate Content Projects, one that referenced the ever-changing-content-processor project, and the other which only had content that didn't need special processing (plain models, textures, spritefonts, etc)

  • Same scenario, except our content takes almost two hours to fully build because there is so much. ;)

    Exactly the same solution too: I separated the single content project into sub-projects.  As an added step I culled pipeline assembly references to just those needed by each sub-project.

  • I have a bit of a problem:

    My solution is divided into 3 projects: game, content pipeline, and the library (most logic/engine) - not the best division (i think), but works fine.

    My game is referencing the library project, game content reference content project, and content project reference library project as well.

    The problem starts when i change a code in the library project, which makes all content items rebuild. the output says it's due to assembly changes in content project, which isn't true.

    i _believe_ it is saying so because the content project is referencing the library project.

    Is there a way to tell VS 2k8 not to rebuild every time a specific reference rebuilds?

    (i will do so when needed, using rebuild instead of the "normal build")

    Yours, Matan.

  • > Is there a way to tell VS 2k8 not to rebuild every time a specific reference rebuilds?

    Sure: just unload whatever projects you don't want to rebuild, or mark them not to build in the Visual Studio Configuration Manager.

    I don't recall whether you can do this for individual content projects, but you certainly can if you move the content into a separate Game Library project, then reference that library from your main game.

  • The problem i am facing is i cannot separate it. my content pipeline is a bit "more", and use some logic written in the library project. i can separate it but i will just have to reference it anyway, and changing it will result in the same way.

    about the rebuild:

    that works great! unloading content project -> and build doesn't rebuild the content every second.. when i need to, i will just reload it.

    Thanks so much, exactly what i was looking for!

  • My problem was I had a source (swf) and it created xml data and pngs, which were bundled and used. Certain situations would cause it to build every time, even with no changes to the source (due to the pngs not having the same data as the swf I assume).

    My repo: The swf was built, but a content pipeline assembly gets modified. This causes a rebuild, but only the pngs get rebuilt, swf isn't 'touched' so the date stays stale. After this it will rebuild every time due to date mismatch.

    This took a long time to track down : ).I would think that when a content pipeline element gets rebuilt that it should modify the timestamp on the source file, but I'm not 100% sure that is the cause. If I rebuild the swf and recompile it works again (yay).

    Recompiling the swf and waiting 5 mins to run the CP *doesn't* cause the rebuilds, so maybe the dates are stored somewhere other than the file timestamp?

Page 1 of 1 (6 items)
Leave a Comment
  • Please add 1 and 2 and type the answer here:
  • Post