Archive for February, 2008

Development Tricks: Debug View

Friday, February 22nd, 2008

I’m often surprised that people haven’t come across this wonderful ex-System Internals (now Microsoft) tool.

Debug View

Debug view allows you to see debug messages written by any application currently running compiled with debug symbols.  To .NET developers, those would be the messages you can write out with System.Diagnostics.Debug.WriteLine(); 

Why would you want to do that?  Well… if you grace your application with a healthy dose of debug messages, you can monitor the performance of applications whilst they’re deployed or in a production environment without having to break out the debugger.  Often a nice quick way to see what a system service is up to, or why your web application appears to be misbehaving.

I currently make use of a combination of this and some IOC magic on a daily basis to monitor in-development services as part of a distributed system (hint: create a wrapper class for writing output messages, then implement it in various ways, Console.WriteLine, Debug.Writeline, etc, even a null implementation to save performance in production environments…) and genuinely don’t know what I’d do without it.

And hell, if you’re really bored it’ll let you know which Windows components are running with debug symbols compiled in (ActiveSync, I’m looking at you…).

Now Playing: Zimmers Hole – Flight Of The Knight Bat

Using C#, Inversion of Control and WCF to produce a generic host for use in distributed systems.

Thursday, February 21st, 2008

.Net 3.0 & 3.5 provides a number of techniques for you to author your own distributed architectures and I’m going to attempt to explain a technique that “worked for me”, allowing me to write a reliable, testable, service based application using the Windows Communication Foundation (WCF).

The goal of this little project is to create a multipurpose standalone server application that can host any code you wish, using WCF to provide other applications access to the code.  The server application should have no idea what it’s hosting, nor be concerned with it.  New services should be installable in to the service host by configuration tweaks alone.  This will result in a low impact standard method to expose API’s and web services to either external or internal applications using just configuration settings.



Throughout this example I’ll be presuming that the reader has a strong grasp of .Net. C#, and Microsoft technologies.  I’ll also touch on nUnit testing and the Castle projects IOC container Windsor, so exposure to either or both of those products would be advantageous.  That said, for the most part, this should just be compile, configure and go.

Castle Windsor:
NUnit: (or mbUnit if you wish…)
and obviously Visual Studio 2005/2008.


Sample Architecture

The following is a pattern that I’ve found to work very successfully:

  • /ServiceApplication
    • /ConsoleHost
    • /SystemService
    • /ServiceContracts
    • /ServiceImplementations
    • /Test_SystemService
    • /Test_ServiceImplementations
    • /CommunicationManager
    • /Installation
  • /ClientApplication
    • /Model
    • /DataManager

We’ll take a look at the client application later, but first a rough outline of the projects that the ServiceApplication consists of.

ConsoleHost is designed to be an exceptionally thin wrapper to provide a console view on the service, it’s concerned only with user interaction and should use CommunicationManager for all of the legwork.

SystemService is an equally thin wrapper around CommunicationManager providing an installable service wrap for your application.

ServiceContracts is an assembly that should contain ONLY the WCF service contracts (C# interfaces) that you intend to make accessible remotely.  You should expect to share this compiled assembly with any client implementations, so ensure this is dependency free (which really shouldn’t be a problem so long as you ensure that you only store interfaces in this assembly).

ServiceImplementations should consist of the ServiceApplication specific implementations of the interfaces defined within ServiceContracts.

Test_SystemService is designed to store unit tests that make use of WCF to connect to the running ServiceApplication, and Test_ServiceImplementations should contain unit tests designed to test the ServiceImplementations directly.  Having these two similar test projects allows you to troubleshoot connection related errors during development independently of code logic related errors.

The CommunicationManager does the brunt of the work, constructing WCF endpoints and maintaining them throughout their lifecycle.  This assembly takes care of the opening and closing of listening services.  It’s constructed of a few key components I’ll detail later.

Installation is reserved for an Installer of your choice, preferably one that can deploy and install Windows Services (WiX or old fashioned MSI projects, I’m looking at you).

I’m not going to go into great detail regarding the SystemService (it’s a standard windows service which calls the same methods the console host will), nor the unit tests or installer.  I’m also not going to try and explain the intricate details of the configuration of WCF, there’s a wealth of resources available online on this topic.  I will however supply some example configuration- enough to make the code functional.


Service Functionality

Define Your Service Contracts

The simplest way to start this project is to define an interface in C# which should describe a few basic operations that you wish to make available as a service (the WCF Service Contract).  I’ve distilled this down into an example I’m calling IExampleContract, the contents of which are:

using System.ServiceModel;

namespace DEJW.ServiceContracts
    [ServiceContract(Namespace = “http://namespace/”, Name = “Example Service”)]
    public interface IExampleContract
        /// <summary>
        /// Returns the uniqueIdentifier supplied back to the calling application.
        /// </summary>
        /// <param name=”uniqueIdentifier”></param>
        /// <returns></returns>
        string Handshake(string uniqueIdentifier);


Define the ServiceImplementation tests

For the sake of following good “XP” practice, the next step should be constructing a simple unit test for the methods you wish to define, and then author the implementation top down.  For the above simple “Handshake” method, the following nUnit test should suffice:

public void HandshakeWithSimpleString()
    string testString = “Hello World!”;

    ExampleContractImpl impl = new ExampleContractImpl();
    string response = impl.Handshake(testString);

    Assert.AreEqual(testString, response);

Write the ServiceImplementations to fulfil the tests

With my (failing, no code!) unit test in place, I’ll now write the code to pass the test.  The implementation should go into a ServiceImplementations project (because when you hand your ServiceContracts over to the consuming application, you’d not want to pass over the service implementation to go with it…).

using DEJW.CommunicationManager;
using DEJW.ServiceContracts;

namespace DEJW.ServiceImplementations
    public class ExampleContractImpl: IExampleContract, IPlugableService
        #region IExampleContract Members

        public string Handshake(string uniqueIdentifier)
            return uniqueIdentifier;


You may have noticed that the implementation features a rogue little interface called IPlugableService that doesn’t appear to need implementing.  This is a concession to the Castle IOC framework and I’ll elaborate on its use in the section on CommunicationManager.

Communication Manager

The CommunicationManager assembly consists of
few key components. 

  • HostManager, responsible for opening and closing WCF endpoints as per the configuration in app.config.
  • IOCFactory, a wrapper for the Windsor containers that helps quickly load a concrete implementation from a configuration value and assembly name.
  • IPlugableService interface, an empty interface used that must be implemented by our service implementations in order for the Windsor container to identify them.
  • IPlugableServiceFactory, an configuration parsing library that inspects configuration and instantiates instances of all the IPlugableServices’ defined in app.config.

I’m not going to go into great detail regarding HostManager, most of the code was adapted from various Microsoft WCF samples with a few generic collections tacked on and a couple of wrapping methods.  There’s nothing high-tech here, it just works.

Usage is very simple:

_hostManager = new HostManager();

As long as your configuration settings are correct, magic happens here.

The key method there is PlugableServiceFactory.RetrieveCollectionOfPlugableServices().  This method loads and traverses the Castle Windsor configuration, and then loads by name every instances of IPlugableService it finds in the config file.  HostManager then uses a typeof on each of these loaded IPlugableService to create a instance of their concrete type, ignoring IPlugableService entirely.  IPlugableService is an interface in place simply so we can tell Windsor what to do.  HostManager then configures the concrete classes as WCF ServiceHosts using the configuration specified.

Configuration Settings

Ensure the following is included in your app.config file:

  <section name=”castle” type=”Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor” />

    <component  id=”service1″
                service=”DEJW.CommunicationManager.IPlugableService, DEJW.CommunicationManager”
                type=”DEJW.ServiceImplementations.ExampleContractImpl, DEJW.ServiceImplementations” />

    <component  id=”service2″
                service=”DEJW.CommunicationManager.IPlugableService, DEJW.CommunicationManager”
                type=”DEJW.ServiceImplementations.ExampleContractTwoImpl, DEJW.ServiceImplementations” />

If you look carefully you’ll see why IPlugableService is important; the Windsor components will attempt to instantiate your components as instances of that empty interface.  The type attribute points to “NameSpace.ConcreteClass, assembly” allowing the Windsor container to find your service implementations.

Next you need to add the relevant WCF configuration, it’s quite lengthy if you’re explicit, but descriptive.

       <binding name=”IExampleContractBinding”
         <reliableSession ordered=”false”
         <security mode=”None”>
           <transport clientCredentialType=”Windows” />
           <message clientCredentialType=”Windows”/>




       <behavior name=”IExampleContractBehaviour”>
         <serviceMetadata httpGetEnabled=”true” />
         <dataContractSerializer maxItemsInObjectGraph=”100000″/>
         <serviceThrottling maxConcurrentCalls=”100″ maxConcurrentSessions=”100″ />


     <service name=”DEJW.ServiceImplementations.ExampleContractImpl” behaviorConfiguration=”IExampleContractBehaviour”>

       <endpoint name=”IExampleContractEndpoint”
                 contract=”DEJW.ServiceContracts.IExampleContract” />

       <endpoint name=”IExampleContractMetaData”

;  contract=”IMetadataExchange” />

           <add baseAddress=”net.tcp://localhost:8000/DistributedServer” />
           <add baseAddress=”http://localhost:8001/DistributedServer” />

     <service name=”DEJW.ServiceImplementations.ExampleContractTwoImpl” behaviorConfiguration=”IExampleContractBehaviour”>

       <endpoint name=”IExampleContractTwoEndpoint”
                 contract=”DEJW.ServiceContracts.IExampleContractTwo” />

       <endpoint name=”IExampleContractTwoMetaData”
                 contract=”IMetadataExchange” />

           <add baseAddress=”net.tcp://localhost:8002/DistributedServer” />
           <add baseAddress=”http://localhost:8003/DistributedServer” />

Obviously your mileage may vary with the above configuration (a lot of those values are values I’ve used in my day job for development purposes, but you’ll want to tighten down lots of those values and, I suspect, enable security for any production system).

Control Application

The control application that goes with this code is practically nonexistent (one of the stated goals) just stick the aforementioned usage example in the main method, followed by some kind of message and a ReadLine() to stop the application exiting.  Something akin to:

_hostManager = new HostManager();

Console.WriteLine(“Press any key to exit”);

For the windows service implementation create a static instance of HostManager and override protected override void OnStart(string[] args), in this method call the StartListening() method on HostManager, and override OnStop to call the StopListening() method for a clean shutdown.


The key benefit to this approach to service hosting is how trivial it makes expanding your services.  In order to add extra functionality to an existing service you need to modify the service contract and service implementation, recompile those two projects and let the HostManager do the rest.  If you wish to host an entirely new service, create a new service contract and implementation, and remember to add a configuration section to app.config, and again, let HostManager take care of the details.


Source code

The source code provided here is NOT a compiling project.  Instead I’ve provided the CommunicationManager project (if you’ve read the above details you’ll realise that’s all you really need), the example ServiceContracts and example ServiceImplementations, alongside the example unit test and an example App.config.

If you wish to use this code, remember you’ll need a copy of the Windsor components, you’ll need NUnit if you want to run the unit test and you’ll need to write your own console / service wrapper.

Some of the code in here was inspired by writing a more specific service for my employer that made me wonder if I could abstract the service host portion of the code into a more general purpose application.  Apparently it was possible!  I’ve not reused any code however I’d imagine the similarities are striking, so whilst not “production tested”, the methods and techniques used should be relatively bug free.  No warranty etc etc, but I hope somebody finds this useful.  It’s definitely the approach I intend to take to authoring services from this point forwards.


Now Playing: Zimmers Hole – When You Were Shouting At The Devil… We Were In League With Satan

Pigs are flying and Microsoft are opening APIs

Thursday, February 21st, 2008

I don’t think I can explain the benefits these actions could have as they’re so wide and varied.  I’m not mistaking them for pure altruism, however for a Microsoft platform developer, I’m incredibly excited by today’s news of opening up API’s and providing comprehensive internal documentation.  I had a quick flick through some of the documentation available already, on the day of announcement, and it seems to be of high quality and revolving around key windows properties.

Happy times!

Mass Effect

Sunday, February 3rd, 2008

I finally finished off Mass Effect today (my first play through).  I don’t think I’ve played a game in a long time that was so good, that as soon as I finished it, I immediately started it again on a higher difficulty.  Absolutely brilliant.  Bioware have managed, in single game, what many authors, film makers and TV writers fail to do over a period of years.  They crafted a fantastic cast of characters that you empathise with and grow with, they give you at least the fantastic illusion of choice as to the fate of these characters, and they’ve created an epic science fiction story that doesn’t feel stale and familiar. 

The plot isn’t the most original science fiction I’ve ever seen, but in a genre that’s done to death, they keep it believable, with a few moments that really catch you off guard.  The first section of the game actually sees a RPG developer create a reasonably freeform game without grind and full of personality and variety, whilst the final act or two of the game features at least one brilliant “oh shit” moment where you discover who the real antagonist of the game is, and then steps the action up by not coping out with a happily ever after ending.  The dialogue throughout is an absolute joy, the choices the player is presented with are realistic and genuinely difficult at times (mostly due to the empathy you develop for your colleagues), the visuals are stunning and the action is well balanced and paced.  I was especially pleased with the way Bioware merged real time combat and RPG “stop motion” combat, it felt fluid and fun.  It’s not quite Gears of War duck and cover action, but when you get to just blow the crap out of everything it plays well and is suitably rewarding.

It’s not without faults, the inventory management is a bit flaky, the AI occasionally makes you shoot it in the back of the head by running through gunfire and using the default character setup it seems like you can become a little too powerful towards the end of the game if you play the side missions correctly (top tip, max out AI hacking on one of your team members as early as you can, and any big nasty Geth become your big nasty Geth), but all of these are tiny flaws in possibly the best game I’ve played on the xbox360 so far.  If you like science fiction, adventure, action or just an excellent RPG, please please buy this game.  It’s apparently the first in a trilogy that are designed to be released over the life span of the xbox360 and I personally can’t wait.

As a non-gameplay note, the music from the ending credits of Mass Effect made me pay attention.  A band I’d never heard of called “Faunts”, the song appears to be from an EP and I’ve sneakily found it on youtube (and the Mass Effect OST).

On a (slightly) different note, I went to see Cloverfield tonight and enjoyed that too.  I expected roughly what I got, the “Chulhu Witch Project”.  The acting was all really convincing, the effects were top notch and the atmosphere was great.  Enjoyed it for what it was.

In summary?  Mass Effect is one of the best games and stories I’ve ever played, and Cloverfield is mighty entertaining.  Hope you’re all well x