Topshelf and IoC containers

2014-02-27 by mookid8000 Leave a comment

To top off my previous post with an example on how almost any kind of application can be hosted as a Windows Service, I’ll show an example on how Topshelf can be used to host an IoC container.

As most developers probably know, an IoC container functions as a logical application container of sorts, helping with creating stuff when stuff needs to be created, and disposing stuff when stuff needs to be disposed, keeping whatever needs to be kept alive alive for the entire duration of the application lifetime.

This way, when we have this Topshelf-IoC-container framework in place, we can use it to activate all kinds of applications.

I’ll show how it’s done with Castle Windsor, but I think it should be fairly easy to port this solution to any other IoC container.

Create a service class that holds the container

First, let’s create a class that implements the Start/ Stop methods of ServiceControl – this class will initialize its Windsor container when it starts, and dispose it when it stops.

I’ve added some logging for good measure – when you’re a backend kind of guy, you come to appreciate a systematic and consistent approach towards logging in your Windows services, and I’m no exception.

class RobotService : ServiceControl
{
    static readonly Logger Log = LogManager.GetCurrentClassLogger();

    readonly WindsorContainer _container = new WindsorContainer();

    public bool Start(HostControl hostControl)
    {
        try
        {
            Log.Info("Initializing container");

            _container.Install(FromAssembly.This());

            return true;
        }
        catch (Exception exception)
        {
            Log.Error("An error occurred during intialization: {0}", exception);

            return false;
        }
    }

    public bool Stop(HostControl hostControl)
    {
        try
        {
            Log.Info("Disposing container");

            _container.Dispose();

            return true;
        }
        catch (Exception exception)
        {
            Log.Error("An error occurred during container disposal: {0}", exception);

            return false;
        }
    }
}

class RobotService : ServiceControl

{

static readonly Logger Log = LogManager.GetCurrentClassLogger();

readonly WindsorContainer _container = new WindsorContainer();

public bool Start(HostControl hostControl)

{

try

{

Log.Info("Initializing container");

_container.Install(FromAssembly.This());

return true;

}

catch (Exception exception)

{

Log.Error("An error occurred during intialization: {0}", exception);

return false;

}

public bool Stop(HostControl hostControl)

{

try

{

Log.Info("Disposing container");

_container.Dispose();

return true;

}

catch (Exception exception)

{

Log.Error("An error occurred during container disposal: {0}", exception);

return false;

}

Use Topshelf to activate the service class

Now we can have our RobotService activated as a Windows Service by adding the following C# spells:

class Program
{
    static readonly Logger Log = LogManager.GetCurrentClassLogger();

    static void Main()
    {
        AppDomain.CurrentDomain.UnhandledException += (o, ea) => Log.Fatal("Unhandled exception: {0}", ea.ExceptionObject);

        HostFactory.Run(f =>
        {
            f.UseNLog();
            f.Service<RobotService>();
        });
    }
}

class Program

{

static readonly Logger Log = LogManager.GetCurrentClassLogger();

static void Main()

{

AppDomain.CurrentDomain.UnhandledException += (o, ea) => Log.Fatal("Unhandled exception: {0}", ea.ExceptionObject);

HostFactory.Run(f =>

{

f.UseNLog();

f.Service<RobotService>();

});

}

Please note that Topshelf needs a little extra help with logging unhandled app domain exceptions, so I’ve added a little bit of Log.Fatal at the top.

Add components to the container to actually do something

Now, just to show some real action, I’ve added a single Windsor installer that looks like this:

public class TestInstaller : IWindsorInstaller
{
    static readonly Logger Log = LogManager.GetCurrentClassLogger();

    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<IDisposable>()
                .Instance(CreateAndStartTestTimer(interval: TimeSpan.FromSeconds(1)))
                .Named("TestTimer")
            );
    }

    Timer CreateAndStartTestTimer(TimeSpan interval)
    {
        var timer = new Timer(interval.TotalMilliseconds);
        timer.Elapsed += (o, ea) => Log.Info("woooH0000! It's going great!!1");
        timer.Start();
        return timer;
    }
}

public class TestInstaller : IWindsorInstaller

{

static readonly Logger Log = LogManager.GetCurrentClassLogger();

public void Install(IWindsorContainer container, IConfigurationStore store)

{

container.Register(

Component.For<IDisposable>()

.Instance(CreateAndStartTestTimer(interval: TimeSpan.FromSeconds(1)))

.Named("TestTimer")

);

}

Timer CreateAndStartTestTimer(TimeSpan interval)

{

var timer = new Timer(interval.TotalMilliseconds);

timer.Elapsed += (o, ea) => Log.Info("woooH0000! It's going great!!1");

timer.Start();

return timer;

}

As you can see, it will start a System.Timers.Timer, configured to periodically log a cheerful statement to the log and shove it in the container to be disposed when the application shuts down. It shouldn’t take too much imagination to come up with more useful and realistic tasks for the timer to perform.

This is actually all there is to it! Of course it can be customized if you want, but what I’ve shown is the only stuff that is necessary to create a full-blown Windows Service that manages the lifetime of application components and logs its work in a way that makes the service monitorable, e.g. by Microsoft SCOM and/or Splunk or whichever way you like to throw your logs.

As a public service, I’ve put this small example project in a GitHub repository for your cloning pleasure. Also, if you have any comments, please don’t hesitate to send them my way. Pull requests are also accepted 🙂

Updated guide to Topshelf

2014-02-24 by mookid8000 6 Comments

I have written about Topshelf several times before, but the API has gone through a few changes over the last couple of years – and since my Topshelf posts are, for some reason, constantly (according to my stats) being (re)visited, I thought it would be in order to show the most current version of Topshelf in action…

Oh, and if you’re reading this and you don’t know what Topshelf is – it’s a library that helps you to quickly make your C# console application into a Windows Service that can easily be F5-debugged as well as installed as a proper Windows Service.

This is how you do it:

Create a new console application

Just do it. Name it something cool, like RobotsOnFire.

Pull in Topshelf with NuGet

Either reach out for your mouse and clickety click a few dozen times… me? I prefer to go

install-package Topshelf -ProjectName RobotsOnFire

1	install-package Topshelf -ProjectName RobotsOnFire

in the Package Manager Console, and this is how I avoid getting a tennis elbow even before I’ve written one line of code.

Remove unnecessary using directives and other redundant crap

This looks stupid – it makes you look like a person who doesn’t care:
before

This looks good – it reaks of the finicky meticulousness that is you:
after

Now, modify your Program class

into something like this:

class Program : ServiceControl
{
    static void Main()
    {
        HostFactory.Run(f => f.Service<Program>());
    }

    public bool Start(HostControl hostControl)
    {
        return true;
    }

    public bool Stop(HostControl hostControl)
    {
        return true;
    }
}

class Program : ServiceControl

{

static void Main()

{

HostFactory.Run(f => f.Service<Program>());

}

public bool Start(HostControl hostControl)

{

return true;

}

public bool Stop(HostControl hostControl)

{

return true;

}

and then press F5, and then you’ll be looking at something like this:

Wow! That was easy, right?! In order to actually do something in your Windows Service, you start a thread or a timer or something similar in the Start method and make sure that what you started is stopped again in the Stop method. In other words, the Start and Stop methods must not block – otherwise, Windows Service Control will not start the service properly.

Since this bad boy is an ordinary Console Application on the surface, it can be F5-debugged and run by executing RobotsOnFire.exe. But in addition to that, you can do this (in an elevated command prompt):

install

which results in Robots On Fire turning up as a Windows Service in Windows:

services

Now, let’s uninstall it again:

uninstall

and then let’s customize a couple of settings:

class Program : ServiceControl
{
    static void Main()
    {
        HostFactory.Run(f =>
        {
            f.Service<Program>();
            f.SetServiceName("ServiceName:RobotsOnFire");
            f.SetDisplayName("DisplayName:RobotsOnFire");
            f.SetDescription("This is my Robots On Fire Windows Service");
        });
    }

    public bool Start(HostControl hostControl)
    {
        return true;
    }

    public bool Stop(HostControl hostControl)
    {
        return true;
    }
}

class Program : ServiceControl

{

static void Main()

{

HostFactory.Run(f =>

{

f.Service<Program>();

f.SetServiceName("ServiceName:RobotsOnFire");

f.SetDisplayName("DisplayName:RobotsOnFire");

f.SetDescription("This is my Robots On Fire Windows Service");

});

}

public bool Start(HostControl hostControl)

{

return true;

}

public bool Stop(HostControl hostControl)

{

return true;

}

which, after installing it again, will show up like this:

where-do-the-settings-go

Topshelf has many additional things that can be customized – e.g. you can perform actions in connection with installing/uninstalling the service, make it install to be run under various system accounts, and – this is one of the cooler things – you can declare a dependency on e.g. a local SQL Server, a local IIS, or any other locally running Windows Service – this way, services will always be started/stopped in the right order, ensuring that e.g. your MSMQ-dependent service is not started before the Message Queueing service.

Ways of scaling out with Rebus #5: MSMQ

2014-02-18 by mookid8000 Leave a comment

I deliberately waited until the last post in my series on how to scale your Rebus work to talk about how to do it with MSMQ. The thing is, MSMQ doesn’t lend itself well to the competing consumers pattern and thus requires some other mechanism in order to be able to effectively distribute work between a number of workers.

NServiceBus achieves this ability with its Distributor process, which is a sophisticated load balancer that communicates with its worker processes in order to avoid overloading them with work, etc.

The Rebus way of doing this is much simpler. I’ve long contemplated building a simple load balancer – one that blindly distributes work in a round-robin style fashion, which I believe would provide a sufficiently powerful and wonderfully unsophisticated way of scaling out your chunks of work.

This means that in a producer/consumer scenario, you would send all the work to the distributor, which would forward pieces of work to consumers in equal portions. It can be shown like this:

rebus msmq load balancer

This is so simple, it cannot fail.

Which is why I’ve made the Rebus.MsmqLoadBalancer package, containing a LoadBalancerService.

Once you’ve executed the following Powershell spell:

install-package rebus.msmqloadbalancer -projectname YourProject

1	install-package rebus.msmqloadbalancer -projectname YourProject

the load balancer service can be started like this (assuming YourProject was a console application):

using(var loadBalancer = new LoadBalancerService("distributor"))
{
    loadBalancer.AddDestinationQueue("worker@machine1");
    loadBalancer.AddDestinationQueue("worker@machine2");
    loadBalancer.AddDestinationQueue("worker@machine3");

    loadBalancer.Start();

    Console.WriteLine("Press ENTER to stop the load balancer");
    Console.ReadLine();
}

using(var loadBalancer = new LoadBalancerService("distributor"))

{

loadBalancer.AddDestinationQueue("worker@machine1");

loadBalancer.AddDestinationQueue("worker@machine2");

loadBalancer.AddDestinationQueue("worker@machine3");

loadBalancer.Start();

Console.WriteLine("Press ENTER to stop the load balancer");

Console.ReadLine();

}

In this example, the load balancer will receive messages from the local distributor queue and forward them, distributing them evenly among the three workers residing on machine1, machine2, and machine3.

If you want to put this bad boy to some serious action, you’ll most likely want to wrap it in some kind of host process – either hosting it in the same process as the producer of your work, or in a Topshelf service or something.

One thing to note though: I haven’t had the chance to try the load balancer myself yet, mainly because my own horizontal scaling experience comes from working with RabbitMQ and Azure Service Bus only.

If you’re interested in using it, please don’t hesitate to contact me with questions etc., and I’ll be happy to help you on your way!