On Friday afternoon I noticed that our CC.Net server had stopped working.  I spent the entire afternoon looking into the cause of the problem to no avail.  Finally I resigned the idea that I was going to have it working before I left for a weekend out of town.  Today when I got back to work it appeared as though the elves that I was hoping were going to fix this issue, had actually taken the weekend off too.  I hunkered down and began troubleshooting again.

The symptoms that I was running into were these:

1. CruiseControl.Net service would start and I would be presented with a JIT Debugger window for errors in the Remoting namespace
2. Service would shutdown (didn’t matter if I tried debugging or not)
3. Sometimes a kernal32.dll exception would appear in the Event Viewer (I think this is related to the JIT Debugger window)
4. Sometimes the CruiseControl.Net service would log information to the ..\CruiseControl.Net\server folder

Originally when I logged onto that server to do some maintenance on Friday, I was presented with a message saying updates had been applied and would you like to restart.  Of course I chose yes and went on my merry way.  Between the JIT Debugger pointing at the Remoting namespace and the updates having been applied sometime before the Friday failures, I figured that there was a problem with the ability for the service to communicate over remoting to localhost.  After spending a number of hours working on this angle, I finally gave up and did what any frustrated team lead does…..I delegated to one of my guys while I went to another meeting on productivity.

When I got back the answer to the problem was quite obvious.  Apparently the guy who was doing maintenance on this server on Friday (nobody point fingers….doh) had modified the ccnet.config file using CCNetConfig.  Being the frequent updater that my current employer is, the version of CruiseControl.Net in use is v1.1.xxxx.  It looks like there may be a bug in CCNetConfig since I specifically chose that version when opening the file and saving it (if you look in your ccnet.config file you’ll see the commented out XML at the top of the file indicating which version of CruiseControl.Net CCNetConfig has labeled the file as), and yet the file was in an invalid format.

I spent a little bit of time looking to see what the problem was, but in the end I decided that a full day chasing the issue was enough time spent there.  What I do know is that the ccnet.config file that I have working currently does contain a far different structure than the one that CCNetConfig created for me.