Here is another patch for CruiseControl.Net. This patch provides support for a Robocopy SourceControl provider. This gives a significant performance increase over the FileSystem SourceControl provider. To integrate this I needed to adjust how CCNet determined if an executable had succeeded, it used to rely on the exit code of the executable being 0 to indicate success, but Robocopy is more complex than that. ProcessExecution-MultipleSuccessExitCodes-Patch.txt And here are the source files and test harness for the robocopy source control provider.

I’ve just picked up a copy of Windows Via C/C++ (PRO-Developer) by Jeffrey Richter and Christophe Nasarre. This is ‘version 5’ of the book that started out as Advanced Windows NT (Advanced Windows). The book has been updated for Windows Vista and other changes that have happened since the last version, Programming Applications for Windows (Microsoft Programming Series). I’ve decided to read it from cover to cover to refresh my knowledge and pick up on any changes.

I’m continuing to tune my continuous integration system. Today I switched the ‘deploy’ projects from using a CC.Net file system source control task to do the deployment to using Robocopy. This has sped things up nicely and made the deployments more configurable. One problem that I had was that the CC.Net “executable” task (the one that lets you run arbitrary executables) assumed that only exit codes of 0 were ‘success’ and Robocopy has a more complex strategy for exit codes (see here).

Yesterday I mentioned that the file system source control provider in CC.Net was a little inefficient. I speculated as to how it might be working and how it might be improved. Well, as the saying goes, assume makes an ass out of you and me… The file system source control provider is actually far far simpler than I expected. It scans the ‘repository’ file system tree and simply looks for files that have been written to since the last check.

Well, it’s about a month since I started running Cruise Control .Net and things have settled down somewhat now and I can almost go a day or two without tweaking my configuration or being tempted to fix issues in Cruise Control itself. For those of you that haven’t been following along: First I realised that the latest (1.3) release of Cruise Control .Net wouldn’t work for me without some hacking.

Barry (who seems to have stopped blogging) recommended this blog to me; Coding The Markets. It’s pretty good if you’re into investment banking development stuff.

If Richard Wolff is reading this then I can’t reply to your emails as your ISP is bouncing my emails with this: `Hi. This is the qmail-send program at ns.mgf4.net. I’m afraid I wasn’t able to deliver your message to the following addresses. This is a permanent error; I’ve given up. Sorry it didn’t work out. Connected to 207.115.36.23 but sender was rejected. Remote host said: 553 5.3.0 nlpi100,DNSBL:To request removal of, 69.

Hacking CruiseControl.Net to work better for my specific circumstances (lots of projects that depend on lots of projects) has resulted in the following patches to revision 3607 of ccnet which I’m just about to submit to the developers. These patches are ‘supporting patches’ to the main ProjectTrigger and integrator changes, I thought I’d start with the simple ones… None of these patches should change existing functionality, all require new, optional, properties to be specified to activate the new code.

The free version of the socket server framework contained code that could cause a deadlock during connection closure if you also have a lock in your derived class. There’s a lock taken out in CSocketServer::Socket::IsValid() that isn’t really required and which can cause a deadlock if you have your own lock in your derived class which you lock in OnConnectionReset() or other server callbacks and which is also locked when you call into the framework via Write() or other calls.

There’s a new release of The Server Framework’s Free Framework, here. This includes the bug fix that was mentioned here.