The presence of the Project A assembly is straightforward. At the publishing stage, write the file to a network drive.
Project B can use the file system source control block to monitor the network file system and run the build based on the change from project A. When this is done, it writes another file to the file system (another directory).
Project C uses the file system control to view changes from project B.
Everything is pretty simple.
If you do not have a common file system, you can also use ftp, scp, or http to move trigger files.
If you prefer, you can initiate the build using the web interfaces invoked during the publishing steps of Project A and Project B.
By answering questions you can get information that Project B does not work (at least) in two different ways.
One could have project B under CC, which served as a proxy for remote project B. Remote project B recorded the file during the publishing phase, and indicated in the file whether it passed or failed. The proxy-B project will control this file, and during the “build” phase, it will read the file and transfer or dump it based on the contents. Project C now just controls proxy B using the CC BuildStatus element.
Another way to solve the problem would be to replace Project B under CC.net with CC DistributedBuilder, which uses JavaSpaces to distribute assemblies to remote agents: http://confluence.public.thoughtworks.org/display/CC/Using+distrib+from+the+CruiseControl + contrib
In the distributed approach, Project B will still run on the Windows computer, but DistributedBuilder will remotely run the script and then return the results to the CC server.