How to get up and running with Rebus

Now that Rebus is present on NuGet, it has become extremely easy to get started. This small guide will show how to build a simple TopShelf service, that will send a message to itself. It should be pretty easy to extend this to a more complete example with multiple services, but let’s just keep it really simple for now.

Create the host process

First, we create a TopShelf host process that has all the necessary stuff to be able to run and be debugged, as well as installed, uninstalled, and be managed as a Windows Service. Precious stuff when you’re building backend processes.

Create a Console Application

Do what the header says – and change the target framework from that bastard “.NET 4 Framework Client Profile” to “.NET 4 Framework”.

Go get TopShelf

Open a package manager console (we’ll need it for the Rebus alpha packages), and

For some reason, you need to download Log4Net manually, even though TopShelf depends on it.

Configure Log4Net and declare the TopShelf service

Now, do something like this in your Program.cs:

and then add some XML to your app.config:

Now you should be able to run the service and see a buttload of log statements, courtesy of TopShelf.

Insert Rebus

Now that we have the host process up and running, let’s make the program do stuff.

Let’s get Rebus

Go to the package manager console again, and do this:

Let’s configure and use it!

Now, you should be able to implement your Start and Stop methods like this:

Now, in order to make the container.Register(...) line from above compile, you need to let Program implement IHandleMessages<string>. Try adding something like this:

If you run the program now, you’ll get some kind of error, saying that the input queue name is invalid. That’s because we haven’t configured Rebus yet. Let’s do that by modifying app.config by adding this:

The InputQueue attribute above tells Rebus to receive messages from the RebusTest.input queue, and the <add ...> elements says to send messages of the System.String type to the same RebusTest.input queue.

Let’s run it

Now you should be able to run it and see something like this on your screen:

If you get the same w00t!!!: HELLLLLO WORLD!!!1 in your console, it means you’re ready to start building stuff with Rebus 🙂

Announcing: Rebus

Preface

Friends and acquaintances might know that I’ve spent the last 6 months or so of my pastime, hacking on something I call Rebus. To cut a long story short, I can tell you that I am a happy NServiceBus user who became very sad when NServiceBus went from being free to requiring a commercial license – not because I think NServiceBus isn’t worth spending money on, but because I think it hurts the adoption of NServiceBus.

Speaking for myself, I have already refrained from using NServiceBus in a couple of smaller projects, where it would otherwise have been an awesome addition.

I seriously considered forking the 2.0 version of NServiceBus, which is licensed under Apache v. 2.0, but I was overwhelmed by the sheer size of the project. This led me to re-implement my favorite features of NServiceBus as Rebus, trying to focus and stay lean along the way.

And here it is: Rebus

Rebus – the core – depends on .NET 4 only. And since .NET 4 has MSMQ, ADO.NET, and binary serialization, you get to send and receive messages transactionally and persist your stuff in SQL Server without anything but Rebus core.

3rd party integration (like e.g. MongoDB, NewtonSoft JSON serializer, etc) is provided through small, dedicated add-on projects. This granularity makes it easier to manage your own dependencies.

Update: And since JSON serialization was deemed to be the preferred form of message serialization, it has been ILMerged into Rebus core since right after this announcement. Therefore, JSON serialization is included in the box and is the default.

There’s currently two ways to get started with Rebus:

  1. Instantiate RebusBus manually, filling in the ginormous constructor with implementations for how you want the bus to run.
  2. Use the configuration API.

Let’s try the configuration API – with the following snippet of XML in your app.config:

and the following piece of code in your app:

you should be up and running with a Rebus bus.

That was a small teaser – there’s more blog posts on the way, I promise 😉

So, what’s the state of this?

Well, that’s actually the whole point of this blog post – I’m currently in a situation where I really feel like putting Rebus to some serious use, but I cannot justify foisting it on a client until I have a big project to prove its worth. And I cannot prove its worth in a big project until I have a client I can fob it on.

That’s where you come in! 🙂

You:
  • You’re building something – it’s not totally mission critical, as in human lives depend on it, but it’s still something.
  • You want some nifty service bus technology to help you build a loosely coupled architecture that will allow your project to flex and bend and integrate with stuff in many years to come.
  • You wanted to use NServiceBus because it’s cool, but you can’t afford the cost up front.
  • You’re reading this blog post, or someone you know read it and is now telling you about it…

If that’s you, then you should meet Rebus!

Rebus:
  • Absolutely free to use and abuse.
  • Very very similar to NServiceBus, allowing you to migrate to NServiceBus some time in the future if Rebus is not enough for you.
  • Pretty simple.
  • Comes with unlimited[1. Within reason, of course – I have a day job, a wife, and two kids, so I’m not answering emails 24/7 – but I’ll go to great lengths to help you get a smooth adoption of Rebus – because that’s just how much I care :)] support from its author.
  • Did I mention it was free?
A match made in heaven?

If you have the slightest bit of interest in what I’m suggesting, please contact me – either via email or on Twitter – and then we’ll talk about what Rebus can do for you. Oh, and please don’t hesitate to contact me – even if you’re NOT planning on using Rebus, I’d like to know why you picked NServiceBus, MassTransit, or Rhino Service Bus instead.

If you’re just eager to try it out, feel free to Install-Package -Pre one or more of Rebus’ NuGet packages.

I judge developers by how many toolbars are showing in their IDE

Usually, I try not to be judgmental about stuff. I like to keep my mind open and to accept people as the beautifully unique snowflakes they are… or something… 🙂

There’s one thing that irritates me though, and that’s C# developers who constantly reach for the mouse to click the tiny crappy toolbar buttons that for some reason seem to have survived in Microsoft IDEs since 1995 VB4. Yeah I’m looking at you! You’re crap!

There is nothing more annoying than pair programming with someone, who cannot even go to another file without having to scroll up and down in Solution Explorer, looking for that file to double-click. And then comes the time to re-run the current unit test… Sigh!!!

Now, if you have any ambition as a C# developer, I recommend you start out every new installation of Visual Studio by

  • Hiding all toolbars (which, unfortunately, cannot easily be done at once – new ones pop up every time you open a new kind of file for the first time).
  • Making all tool windows auto-hide (i.e. click the little pin on e.g. Solution Explorer, making it collapse – usually to the right side of the screen).

That will make your work environment resemble the picture on the right (especially if you have a 1337 dark color scheme like mine) – see: no clutter! No stinking buttons to disturb your vision while you’re swinging the code hammer! And, it will serve as an incentive to start using the keyboard some more.

Now, in order to be able to actually work like this, it’s essential that you know how to navigate using the keyboard only. Therefore, here’s a few very basic shortcuts to get you started[1. Assuming of course that you’re using Visual Studio with standard keyboard settings and R# with Visual Studio keyboard scheme]:

  • Navigate to any open window in the environment: Ctrl + Tab + arrows while holding Ctrl.
  • Jump to file currently being edited in the Solution Explorer: Shift + Alt + L.
  • Jump to the R# test runner: Ctrl + Alt + T.
  • Pop open the context menu: Shift + F10.

Now, with these in place I think it should be possible to start doing all navigation with the keyboard only. And then, when you get tired pressing Shift + F10 and choosing stuff in the menus, you can start learning the real shortcuts to everything.

Using the keyboard for the majority of all tasks has several advantages – in addition to relieving the strain on the right wrist, arm, and shoulder, you also get the advantage that your navigation and execution of common workflows is sped up, allowing your work pace to better match the pace of your train of thought.

Also, I won’t judge you 🙂

Just a personal observation regarding the recent IoC debate on Twitter

Systems, where I’ve started out “as simple as possible”, and later wished that I had baked in an IoC container from the beginning: Several.

Systems, where I’ve baked in Castle Windsor from the beginning, and where I later wished that I hadn’t: 0.

#justsaying

(IMO, using an IoC container does not increase overall complexity – it just moves some of the complexity out of my code, and into a thing that implements a bunch of useful patterns in a slightly more opaque way than if I’d implemented those things myself.)