Skip to main content

A Single-Featured App – Introducing ‘Queue View’

I’ve been working with NServiceBus at work lately, and it’s useful to be able to look at the messages that are landing in the queues. Unfortunately, the MMC snap-in provided by Microsoft is woefully inadequate when it comes to this task. There are some commercial tools available, but I thought I should be able to find a free tool out there somewhere with this seemingly simple functionality.

I found Msmq Studio, a nice little app that enables you to do many different queue management tasks both locally and remotely. However, it doesn’t seem to work on my machine now (or any of the servers at work), though it did at one time. I need something reliably do one simple thing, so I decided to take the opportunity to experiment with WPF, a platform for which I’ve never written an app. The result is what I’ve tentatively titled ‘Queue View’:

 

This app does one thing and one thing only – it shows, in XML format, the contents of messages in private queues on the local machine (assuming, of course, the messages have been serialized and stored in XML). Here is some of the relevant code:

public class MessageQueueGateway : IMessageQueueGateway
{
    #region IMessageQueueGateway Members

    public MessageQueue[] GetPrivateQueuesByMachineName(string machineName)
    {
        return MessageQueue.GetPrivateQueuesByMachine(machineName);
    }

    #endregion
}

public class PlainXmlMessageFormatter : IMessageFormatter
{
    #region IMessageFormatter Members

    public bool CanRead(Message message)
    {
        return true;
    }

    public object Read(Message message)
    {
        XmlTextReader xmlReader = new XmlTextReader(message.BodyStream)
        {
            WhitespaceHandling = WhitespaceHandling.Significant,
            ProhibitDtd = true
        };

        var xml = XDocument.Load(xmlReader);

        return xml.ToString();
    }

    public void Write(Message message, object obj)
    {
        throw new NotImplementedException();
    }

    #endregion

    #region ICloneable Members

    public object Clone()
    {
        throw new NotImplementedException();
    }

    #endregion
}

Because of the way I used it, there really was no reason to make PlainXmlMessageFormatter implement the IMessageFormatter from System.Messaging, but I figured, “Why the hell not?”

In the UI, the main form’s controller has an event handler that looks like this:

private void view_MessageSelected(object sender, MessageSelectedEventArgs e)
{
    selectedMessage = (from message in selectedQueue.GetAllMessages()
                       where message.Id == e.SelectedMessageIdentifier.FullIdentifier
                       select message).SingleOrDefault();

    var messageBodyFormatter = new PlainXmlMessageFormatter();
    var messageBody = messageBodyFormatter.Read(selectedMessage).ToString();

    view.DisplayMessageBody(messageBody);
}

You can get the code here. The solution was created in VS 2010 Beta 1. Binaries are included in the ‘Build’ folder. This is essentially pre-alpha software. If you run it on a machine that doesn’t have .NET 3.5 or MSMQ 3.0 installed, it will probably explode.

Comments

Popular posts from this blog

Who I'm Is

I am a junior .NET developer currently working in Chicago, IL. I am starting this blog in order to enhance my knowledge of programming subject matter. Hopefully, someone else will be helped along the way. This first post will probably be edited soon...

Stubbing Static Methods with PostSharp

TypeMock uses the Profiler API to allow mocking, stubbing, etc. of classes used by code under test. It has the ability to handle sealed classes, static classes, non-virtual methods, and other troublesome-yet-oft-encountered scenarios in the world of unit testing. Other frameworks rely on proxies to intercept method calls, limiting them to be able to only fake virtual, abstract, and interface members. They also rely on dependecy injection to place the proxies as the concrete implementation of calls to the abstracted interface members. Anyone working with a legacy codebase is bound to run into static method calls (especially in the data access layer), dependencies on concrete types with non-virtual methods, and sealed class dependencies (HttpContext anyone?). The only way to unit test this without refactoring is with TypeMock. I've never used TypeMock, and I'm sure it's a great product, but it's not free. I decided to spike some code to see if I could solve the prob...

Strongly-Typed Property Constraints in Rhino Mocks

UPDATE: As I suspected, this functionality was right in front of my face – it’s called PredicateConstraint in Rhino Mocks. I also realize that I managed to completely ignore the existence of Predicate<T> in the framework, and write my own predicate delegate. Hey, I was on a roll. Rhino Mocks has a PropertyConstraint class that allows you to check the values on properties of objects passed into the method as part of the verification for that method being called. Unfortunately, the name of the property is specified as a string, which means the benefits of strong-typing that Rhino Mocks is normally so good at preserving are lost. Here’s an example (using Rhino Mocks 3.3 and .NET 2.0): [Test] public void Main_Form_Should_Show_Start_Panel_On_Load() { MockRepository mockRepository = new MockRepository(); IMainFormView mockView = mockRepository.DynamicMock<IMainFormView>(); IEventRaiser loadEventRaiser = GetEventRaiserFor(delegate { mockView.Load += null; });...