C# Queue or ServiceBus with no dependencies?

Question

Is there a product (ideally open source, but not necessary), that would enable a zero dependency deployment? every service bus or queue library I've been able to find has a dependency on one of the queue apps (like msmq), or a database. I would like a very lightweight solution that I can just add a reference to my application, build it, and deploy it with as little configuration as possible.

In an ideal world, the queue/service bus would run on IIS, and allow web and rich clients to talk to it.

Such a tool would be ideal for fast prototyping of large distributed systems on a local development machine.

Answer 1

Rhino Queues from Ayende is exactly what you are looking for, this is the blog post introducing it:

http://ayende.com/Blog/archive/2008/08/01/Rhino-Queues.aspx

I think that all of the limitations mentioned in this post have been fixed since then.

From the blog post, what rhino queues is:

• XCopyable, Zero Administration, Embedded, Async queuing service
• Robust in the face of networking outages
• System.Transactions support
• Fast
• Works over HTTP

Answer 2

In a similar vein to ShuggyCoUk's suggestion, you could rig up a queue (or queues) using the Windows built-in ESENT database (comes already installed with Windows). There is a managed code access library (open source): http://www.codeplex.com/ManagedEsent. If you stick with writing / reading CLOBs or BLOBs, it should work just fine. If you want to be really clever, you can use NServiceBus and write (contribute?) ESENT-flavored subscription storage and transports. There are some forays into using ESENT on Ayende's blog as well (you'll have to poke around his SVN repository for the juicy bits).

Answer 3

If you're happy to be:

1. Windows specific
2. Limited to the local domain
3. Seriously limited in the message size supported
4. Wrap the underlying win32 calls in P/Invoke
5. Deal with the polling yourself
6. Deal with the hacks needed to allow back and forth communication
7. Deal with the shared config needed to keep the names in sync

Then a quick wrapper around the windows MailSlot API might be sufficient.

This simple example is a reasonable basis to start.

This article has some further information but assumes the use case is via a control (rather than a Component as it should be) as well as some poor WinForms integration so should be considered for incidental reading rather than a basis for any library.

This article is C++ but is of a higher standard (and a commenter has extended it to support the batching of larger messages into several smaller ones).

You get 424 bytes (so with .Net 212 chars) you may want to drop to ASCII to double your useful message length if you are talking text.

Note that despite its simplicity, limitations and lack of features it does provide multicast delivery, something often complex to layer on a point to point protocol yourself.