CruiseControl.Net and WCF

CruiseControl.Net

I’ve been using CruiseControl.Net for years. As a Continuous Integration (CI) server it is without peer in the open source community (heck I even think it’s better than some of the non-open source versions). I like it so much that when I changed to my new job a year back that first thing I did was set up a CruiseControl.Net server.

However as much as I like the application there are a few things that bug me. One is the dependence on .Net Remoting for communications between the client (CCTray) and the server. I know it’s possible to use an HTTP transport but I’ve never had any success in getting it to work as nicely as the Remoting transport.

Until my new job I was able to live with it. But at my new job we use a Virtual Private Network (VPN) for remote access, and sometimes it’s nice to work from home. The down side is the VPN only allows certain ports – everything else gets blocked. And surprise, surprise the port that remoting uses is blocked. I could swap to port 80 but then I won’t be able to use the web sites on our build machine (it also hosts a number of other development tools like our source control and bug tracking applications), plus I think the web dashboard is critical for investigating why the build failed.

So it’s time to delve into the world of Open Source and get involved in improving an application. Initially I’m planning on adding WCF to CruiseControl.Net, but I also have a few other ideas to add in (more on them later).

Welcome to Open Source

I read through the instructions on getting involved in development and one of the things it recommended was sending out development ideas to the group of developers involved. So I joined the mailing groups and asked of their opinion on WCF. Overall the feedback was that it sounds liked a good idea – with one caveat. This was it needs to work in Linux under Mono – which doesn’t implement WCF (yes I know there is the Olive project, but it doesn’t seem like much is happening with it). So any development on adding WCF to CruiseControl.Net mustn’t break compatibility with .Net 2.0 (which added some challenges considering WCF is part of .Net 3.0 and later).

To get around this what I’ve been doing is making the WCF components as extension components to CruiseControl.Net and CCTray. The first part is actually adding the extension points to both the server and CCTray (neither of them has the deep integration points that I’m after).

The Nuts and Bolts

My initial work has involved adding some extension points to the server and testing whether it is possible to expose some functionality as a WCF service. As I’m wanting the WCF service to start and stop when the server does I’ve added an interface called ICruiseServerExtension. This exposes four methods:

1. Initialise()
2. Start()
3. Stop()
4. Abort()

Start(), Stop() and Abort() are called by the server when it starts, stops or aborts (simple enough). Initialise() is called when the extension is first loaded. To do this I have added a new method to CruiseServer called InitialiseExtensions(), plus added an extra parameter to its constructor. The extra parameter is simply a List<ICruiseServerExtension> of all the extensions to load (more on how this list is generated later). If there are extensions in the parameter then InitialiseExtensions() is called. This performs the actual loading of the extension object then calls initialise and passes in the CruiseServer instance plus the configuration for the extension.

The list of extensions to load is stored in the app.config file for the server. When CruiseServerFactory performs the creation of a new local ICruiseServer it also loaded the definitions from the config file. I added ServerConfigurationHandler to handle the parsing of the config and return the list of extensions.

That pretty much explains the new extensions to the server side of CruiseControl.Net to allow WCF without forcing everyone to use .Net 3.0 or later. In my next post I’ll talk about the actual WCF extension and how it works.