Yes folks, my normally stable life has had one rather short
on-again-off-again relationship with MSMQ.  A while back I posted
that I was starting to do some work with MSMQ,
but it ran into one rather bizzare week.  The queue must have been
to obvious of a solution to…well…..queue messages for processing,
so a week was spent going back and forth with the client about
implementing our own “queuing” solution.  They proposed that we
shouldn’t use MSMQ (the IT department didn’t want to have to support
it), but rather we should build a queuing solution using .NET and a DB2
database.  Reflecting on my trials with the Data Model To Bind Them All, I wanted no part of designing and getting another logical and physical data structure approved.  Gollom’s idea was that we should build our own multi threaded code that ran as a Windows service and poll the DB2 database.

Anyways, after a week of tap dancing and a lot of frustration on
Aragorn’s part, at 4 on Friday of said week, we were told that we could
go ahead with the MSMQ system that Aragorn had originally
architected.  Five days and we were back where we started.

This whole post started because today was the day that my MSMQ code
finally went into our functional test environment.  It works so
sweet.  One COM component, with two methods in it’s interface, on
a dedicated MSMQ.  The COM component is called by one of two
triggers, each of which is dedicated to it’s own queue (the two queues
belong to two different business processes).  The COM component
code is just a shell that peeks the message on the queue that fired the
trigger, calls a webservice which does all of the business logic
processing, and then cleans the message off of the queue if there is a
valid return value from the webservice.

The queues both are private which, after some failing code and
research, means that the code can not call the MessageQueue.Exists
method or it goes boom. 

The second thing that I had to figure out was how to translate the
MessageID (as variant) parameter from an object data type in the
parameter list of my C# function to a string value representing the
actual message id.  When you look at the Message Queuing snap-in
for MMC, and you list the messages in the queue you can see the
MessageID in one of the columns.  The data shown is a GUID
followed by a “/“ and an identifier number.  In the C# code the
MessageID arrives as an object datatype and upon closer inspection is
actually a byte array.  You can create a Guid datatype using the
constructor that accepts a byte array, so I tried this.  boom
Turns out that the byte array is not the expected 16 length that a Guid
would be, but rather an 18 length array.  So being the observant
guy I am I figure that the last two items represent the identifier
number and the “/“.  Well the value for both points in the array
changes on every message so that rules out the possibility that one of
them is the “/“.  Slim helped me out with this because I couldn’t
come up with this convoluted thought process.  He says “take the
last value in the array, multiply it by 16 and then again multiply it
by 16.  After that add the second last value in the array.” 
I shake my head thinking, this guy has had one to many protien bars
today, but I try it anyways.  Sure enough that does the trick.

Another thing that I learned is that debugging triggers calling COM
components calling webservices on a different machine is not
easy.  I was lucky and had a virtual machine for the MSMQ machine
and a separate one for the webservices, both of which have VS
installed.  To debug this you need to first send a message to the
queue to prime the .NET runtime in the trigger service process. 
After that has happened you should go to the MSMQ machine, purge the
queue (in case the message is still there) and attach VS debugging to
the trigger service process.  On the webservices machine, start VS
and attach it to the IIS process so you can debug the webservice
calls.  Now all you need to do is send a message to the queue and
voila, you are debugging.

The last thing that I suggest is that you create a Pre-Build event to
stop the trigger service and a Post-Build event to start the
trigger.  It makes building so much easier.

I’m the Igloo Coder and thank you for your patience…..the queue will be serviced on a first come, first serve basis.