Have a fairly big project going on with a lot of content to build.  Build is done by invoking msbuild on a command line.  What is weird is that sometimes doing an incremental build will cause the content build process to report this:

    Rebuilding all content because ContentPipeline.xml could not be read

Even when the ContentPipeline.xml file has not changed since the last successful build.  It comes up intermittently:

- when new items have been added to or removed from the msbuild project.
- when one or more content files have been modified since the previous build.
- after a build fails.


Has anyone else experienced this?

Could the ContentPipeline.xml file be read-only? (any chance you accidentally checked this into a source control system?)

Could some other process have it locked? (for instance if you somehow triggered more than one overlapping build at the same time?)

The file is never read-only, but the point about it being locked is a possibility since I am launching the build in a separate process.  The processes are managed by a custom .net application that prevents overlap, but if they are somehow leaking file locks (like say when the process is killed unexpectedly) then that could have something to do with it.

Although I have no way to test conclusively, the problem appears to be some sort of synergistic effect between the build process and a FileWatcher I pointed at the project file.  It hasn't come up again since I started disabling the file watcher before builds.

Thanks for your input Shawn.

Hate to say, but it still happens just much less frequently.  Just leaving unresolved for the time being, this one is elusive.

Some new information:

When the pipeline framework reloads an intermediate xml during an incremental build and a type cannot be deserialized it throws an InvalidOperationException.  This makes sense, and had I been using the VS IDE to perform incremental builds it would have been obvious very quickly.

However when invoking msbuild in my own environment as our team has been doing the observed behavior is different.  Instead of getting an InvalidOperationException report, I receive a "contentpipeline.xml could not be read" error on the console and the pipeline performs a full rebuild.

So my new question is why would invoking msbuild from the command line cause this cryptic behavior instead of reporting the expected invalid operation?