WCF Custom Protocol

The Story So Far…

This is just a quick recap of what we’ve done so far. If you’ve been following along you can probably skip down to the next heading.

This series has been based on the task of adding Windows Communications Foundation (WCF) to CruiseControl.Net. However there was one condition that made it a bit harder – the additions must not force an upgrade to .Net 3.0/3.5 or add code that can’t be compiled on Mono (e.g. for Linux users).

To get around this condition I first extended the CruiseControl.Net server to allow developers to write their own custom extensions that hook into the server process. With this in place I then developed a custom extension that added a WCF service host to the server, designed a contract of what would be provided and implemented the interface.

The next step was to add a router to the dashboard to automatically forward requests onto the server.

With these steps in place we were ready to tackle the client – CCTray. The next two posts covered adding the ability to add custom protocols to CCTray and to be able to configure them. This post now handles the final step – implementing a custom protocol to handle using WCF.

A Simple Task

In order to add a custom transport protocol, there are three interfaces that we need to implement:

• ITransportExtension
• ICruiseServerManager
• ICruiseProjectManager

ITransportExtension is the new interface we added to allow custom protocols, while ICruiseServerManager and ICruiseProjectManager already existed in CCTray. We need to implement these as they provide the glue between our transport and CCTray’s inner workings. They are created by calling RetrieveProjectManager() and RetrieveServerManager() on the ITransportExtension interface.

I started a new project called CCTrayExtensions and implemented the interfaces as follows:

• WcfExtension implements ITransportExtension
• WcfServerManager implements ICruiseServerManager
• WcfProjectManager implements ICruiseProjectManager

The last two classes open a WCF client and call the appropriate method on the client. Yes, all they are is pass-through classes to send the actual requests onto the server. They use auto-generated code – all I did is call svcutil on the WCF endpoint.

WcfExtension handles instantiating WcfServerManager and WcfProjectManager, plus it also displays a configuration dialog and converts between Settings (the property on the interface) and the internal settings (e.g. the transport binding to use). The configuration dialog is a class called WcfConfigurationWindow - this looks like the picture below:

WCF Extension Configuration Dialog

The binding is stored in an enumeration – TransportBinding. As endpoint is stored in the Url property the only value Settings needs to store is this binding, so all the extension does is convert the binding to a string and back.

The final important task of WcfExtension is to open and close the clients. WcfExtension handles the open so it can retrieve the binding and endpoint and correctly configure the client. Close is just to make sure everything is tidied up correctly – plus later on I plan on looking at caching the client so we don’t need to open a new client everytime (which can become expensive for some bindings).

And that’s all there is to the extension – most of the hard work has already been done in adding the custom transport protocol to CCTray.

And In Conclusion

This concludes adding WCF to CruiseControl.Net – both on the server side and the client side. This involves a set of changes to the core libraries, to allow extensions, plus some WCF-specific extensions, so we don’t break our Mono compilation requirement. I’ll add the code to JIRA under two patches – extension-enabling code, plus the actual WCF extensions.

However, I still have a few things to tidy up, so I won’t stop this series just yet. Here are some of the other items I’m thinking of covering:

• Unit testing the code (yes I did write unit tests, but for these posts I wanted to focus on the actual functionality)
• Modifying the installers – it would be nice to get the installers to also install the WCF extensions for those who want it
• Additional WCF functionality – security, logging, dual-channel communications
• How to write a server extension, and also how to write a custom transport – these will be step-by-step guides (if anyone wants to try their own extensions)
• And hopefully an overview of the whole series

As you can see, I still have plenty of ideas on what to write! However, now that I’ve finished documating most of my work to date it takes to get back into some development, so the documentation will probably slow down (I’ve been focusing on the documentation over the past week so I don’t forget anything.)

Hope you enjoy what I’ve done so far. And if anyone has any questions on what I’ve done, or suggestions on improvements, please let me know.