Recently I ran into an issue with a project failing to build on an automated build server using CruiseControl. When I looked into the build log I saw that the Post-Build project was failing with the error message:

"error PRJ0019: A tool returned an error code from "Performing Post-Build Event..."

This was most frustrating especially since the solution was building without issue on my local development environment.

The Post-Build project was a C++ project that basically called several batch files to unregister/register assemblies, copy resources and supporting files, and place other dependencies in the GAC. I decided to run each of the batch files manually to see if that would provide more information as to why this project was failing. This lead me to determine that the batch file that was placing assemblies in the GAC was the culprit and that it was failing to find a particular assembly. The missing assembly was the output of another project.

The project that was not producing the expected output was another C++ project that called a batch file. This batch process was actually embedding resource files into an assembly and then copying the assembly to the expected location. The real confusion started when I looked back into my Subversion log and noted that nothing had changed in this project in more than 2 months! It was almost as if the project had stopped building altogether. But what would cause that?! The Configuration Manager, obviously!

Checking the solution's Configuration Manager settings, I found that the project that was not producing any output was in fact not selected to be part of the build process when the "Any CPU" platform was selected. This was the problem! I had recently updated the CruiseControl configurations to force the solution to be built targeting the platform "Any CPU". As a result, the project that was at the root of the problem was not configured to be built and the post-build process was failing when it couldn't find what it needed.