I recently needed to know a little bit about MSQM, so I put together a very basic little prototype.

MSMQ has a number of features, but I think the obvious ones are:

• it's a Microsoft product (not sure if that’s a feature, but what the hey)
• It's included in the OS from XP onwards
• It's wrapped up in .NET in the System.Messaging namespace
• It's pretty easy to use

It may not be the fastest or the best, but I think that feature set makes it a good choice for dipping your toe in the world of message queues.

We can start by enabling MSMQ in the control panel (under Windows Features). This will start up a service and we will be good to go. First of all we want to create a source of messages. Here we just send a very basic string. In practice you may want to create a message class, perhaps with a message type, Id and maybe a serialized DTO payload.

	// create a queue
	if (!MessageQueue.Exists(_queueName))
	{
		MessageQueue.Create(_queueName);
	}

	// send a bunch of messages
	for (int i = 0; i < 100; i++)
	{
		// slow things down a bit so we can see what’s happening
		Thread.Sleep(100);
		SendPublic(i);
	}

	public static void SendPublic(int i )
	{
		var myQueue = new MessageQueue(_queueName);
		
		string body = string.Format("{0} Public queue by path name.", i);

		var msg = new Message(body);
			
		msg.Formatter = new MessageFormatter();

		myQueue.Send(msg);
		Console.WriteLine(body);
		return;
	}

By default MSMQ uses an XML message formatter, and reading the message body is done through streams. This is sometimes a bit inconvenient. I’ve added a simple message formatter (nicked from MSDN) to ease things.

	public class MessageFormatter : IMessageFormatter
	{
		public bool CanRead(Message message)
		{
			return true;
		}

		public object Read(Message message)
		{
			//Obtain the BodyStream for the message.
			var stm = message.BodyStream;
			stm.Position = 0;
			//Create a StreamReader object used for reading from the stream.
			var reader = new StreamReader(stm);

			//Return the string read from the stream.
			//StreamReader.ReadToEnd returns a string.
			return reader.ReadToEnd();
		}

		public void Write(Message message, object obj)
		{
			//Declare a buffer.
			byte[] buff = Encoding.UTF8.GetBytes(obj.ToString());

			//Create a new MemoryStream object passing the buffer.
			var stm = new MemoryStream(buff);

			//Assign the stream to the message's BodyStream property.
			message.BodyStream = stm;
		}

		public object Clone()
		{
			return new MessageFormatter();
		}
	}

We can then start up several process, just simple console apps, to listen to the queue and read the messages. I was running three or four, and they would read the messages off the queue in a round robin fashion. I found that quite pleasing :)

	public static void MonitorQueue ()
	{
		var myQueue = new MessageQueue(_queueName);

		// enter an idle loop till a message is recieved
		while (true)
		{
			var msg = myQueue.Receive();
			// Process the journal message.
			if(msg != null)
			{
				msg.Formatter= new MessageFormatter();
				
                // read the payload via the BodyStream
				var rdr = new StreamReader(msg.BodyStream);
				var str = rdr.ReadToEnd();
				// or read it directly thanks to the message formatter
				Console.WriteLine(msg.Body);
			}
		}
	}

I’m writing this at home and immediately discovered a few problems that are casting quite a few shadows on MSMQ.

It seems there a few limitations when running MSMQ when you aren’t on a domain (which would be pretty much everyone when they’re not at work, geeks excepted). At work (on a domain) I had no trouble. The messages were sent from one process and several listening processes merrily picked them up and ran with it. Life was good. At home (on a workgroup) my most trivial test does not work.

I’ve only barely scratched the surface here and I’m not sure I like what I’m smelling.

I’d strongly think twice before using MSMQ. If you’re rocking the “enterprise” and building things for a known environment then by all means. If you need to cross boundaries (network, OS, etc) or you want to run over the internet, you want it to “just work” – maybe look a little deeper. RabbitMQ, ZeroMQ, nServiceBus, maybe there is something else out there.

Update: So... I should have read the error message, but it was late. There were a couple of problems with WORKGROUP mode.

The first one I do not really understand (I guess I need to RTFM). If you "Manage" your computer you can see a Message Queuing node has been added. I created a queue directly there, copied the name (something like machinename\private$\testqueue) and used that. All good. Apparantly you can only use private queus in WORKGROUP mode and must reference them with a specific naming format. I found a few forum posts alluding to this, but no definitive answer anywhere. I'm sure it's mentioned somewhere in MSDN...

Secondly, although you can't see it here :) I was also enumerating the public queues on my machine, as a check that the queue was created.

Calling MessageQueue.GetPublicQueues is not supported in WORKGROUP mdoe, which was a bit of red herring. I love the MSDN documentation which lists whether the method is available. Guess the answer is no?