Today's enterprise applications are multi-tiered and interop with many other systems in the enterprise. Users demand easy to use, responsive and sophisticated applications or they will avoid using it. Reliability and responsiveness do not come easy. Reliable exchange and processing of data (messages) in itself is a time consuming and complex undertaking. Microsoft Message Queue server, short MSMQ, provides exactly that - guaranteed and reliable message delivery. It provides an easy way to send messages between different applications or to process messages asynchronously.
Many back-end processes can be long-running. You want to separate these processes from the user-interaction. You want to be able to store the message and process it asynchronously while the user can go on and do other things. Then, when the message has been processed you want to provide a means of notifying the user about its result. Asynchronous processing is key for being responsive to the user and can also become complex. Think about the following example in a typical eCommerce application. The user purchases some goods from your site and uses a credit card for its payment. In real life that means calling out to a credit merchant to verify the credit card and securing the funds, shipping of the goods, updating your inventory status and making sure to re-stock your warehouse. Some of that you want to do in real time and some of that you want to do asynchronously. But all these interactions need to happen in a reliable fashion. You can't charge the customer and then for whatever technical reasons not ship the goods. You also want to be assured that your inventory status gets updated and sold goods are replaced. Any technical brake-down in that process means a negative experience for customers and high unnecessary costs. Reliable and guaranteed message delivery and processing avoids all this. And any messaging solution like "Microsoft Message Queue" server can make it easy to provide this guaranteed, reliable and asynchronous message processing.
Overview of Microsoft Message Queue server
MSMQ comes as part of the Windows OS (MSMQ 1.0 with Windows NT 4, Windows 95 and Windows 98; MSMQ 2.0 with Windows 2000; MSMQ 3.0 with Windows 2003 and Windows XP). This article concentrates on MSMQ 3.0 running on Windows 2003. You can find a number of whitepapers and information on the Microsoft site (click here). You can install MSMQ through the "Add/Remove Windows Components" (under the component "Application Server" and "Message Queuing").
Queues are used to store and route messages. Applications send messages to queues and receive/read messages from queues. There are two different types of queues - private and public queues. Private queues do not provide any routing. Applications can send messages to private queues and other applications or other layers of the same application can then read these messages from the same queue of the same MSMQ instance. Private queues are accessed through "Machine name\Private$\Queue name", for example "MyMachine\Private$\Orders". If MSMQ is installed on the same machine as your application then you can replace the machine name with a dot, for example ".\Private$\Orders". Private queues do not provide any routing but can still be accessed remotely. So you can have a workgroup where one machine has MSMQ installed and all other machines in that workgroup can access this MSMQ instance. Private queues are your choice if all clients/machines accessing the queue are in close proximity and have a fast and reliable connection between them. A good example would be an application which splits up the order placement, order processing and order processed notification into three separate layers but all layers are in close proximity. All three layers can use the same MSMQ instance with one or multiple private queues to exchange messages reliable and easy.
Public queues on the other hand provide message routing. Public queues are your choice if your applications are distributed or have to deal with unreliable communication mediums. A good example would be to have order placement and order fulfillment in different geographical locations or even be performed by different companies. Take an eCommerce portal which resells products from other merchants. You want to take the orders with your application and then reliably route these orders to each merchant for the fulfillment. This means you might have to send these orders over the internet to merchants residing all over the country - a distributed environment with an unreliable communication medium in between. You would have a MSMQ server in close proximity to the servers hosting your eCommerce application and have a public queue for each merchant. The eCommerce application would place orders in the appropriate public queues and then rely on MSMQ to guarantee the delivery. Merchants would rely on the same means to send notifications back to the eCommerce site that orders have been processed. Public queues are accessed through "Machine name\Queue name", for example "MyServer\Orders". You can also replace the machine name with a dot if your application resides on the same machine as MSMQ.
MSMQ can be deployed in two modes - workgroup mode or domain mode. The workgroup mode provides only private queues. So there is no message routing available in the workgroup mode. The domain mode provides private queues and public queues. But the domain mode requires that the machine you install MSMQ on is part of a domain and that the domain uses Active Directory. When you install MSMQ in the workgroup mode you only require the components "Common" and "Triggers". When installing in the domain mode you need the components "Common", "Active Directory Integration", "Routing Support" and "Triggers". When installing in domain mode you can set up sites and site links which determine which queues replicated and how messages are routed. This goes beyond this article.
Private queues are a bit faster then public queues. Think about your requirements to determine which type of queue you need to use. The type of queue determines which MSMQ mode you need. If all clients accessing MSMQ are in close proximity and have a fast and reliable medium to access it, then use private queues and install MSMQ in workgroup mode. If you have a distributed environment or an unreliable communication medium you need message routing which requires public queues and you install MSMQ in domain mode. MSMQ installs two windows services - "Message Queuing" and "Message Queuing Triggers".
There is also an administrative interface which you find under "Computer Management". Under the item "Services and Applications" you find an entry called "Message Queuing". You can view all private and public queues. You can create new queues, edit the properties of existing queues and also delete existing queues. Under each queue you find three items:
- Queue messages - Shows you all the messages currently sitting in the queue. You can view the properties of each message but you can not change it. You can not create a new message or delete an individual message. You can remove all messages by right clicking on "Queue Messages" and selecting "All Tasks | Purge".
- Journal Messages - When you create a queue you can also enable a "Journal". This means when a message is received/read from that queue a copy will be placed into the journal of that queue. So you have a copy of every message read and processed from that queue. Regularly purge messages from the Journal which are no longer needed otherwise it will grow for ever.
- Triggers - Allows you to register a trigger to be called when a message is placed into this message queue. When setting up the trigger you can specify whether a COM component is called or an external executable (more on this later on).
Beside private and public queues you find also an entry called "System Queues". These are system generated queues which you can not modify or remove. Underneath you find three queues:
- Journal messages - When you have enabled the "Journal" of a queue then a copy of the message is placed in the journal of that queue when read/received. If the journal of the queue is not enabled then a copy is placed in the journal under system queues. This gives you control to have a journal per queue or one system journal for all queues.
- Dead-letter messages - Places a copy of every message which can not be delivered or expires before it is delivered or expires before it is received/read.
- Transactional dead-letter messages - Same as the dead-letter messages queue but for all transactional messages. See more later on about transactional messages.
You can also programmatically create and delete queues as well as set the properties of existing queues.
A look at MSMQ and the .NET framework
The .NET framework provides a number of classes to work with MSMQ, located in the System.Messaging namespace. The two most important classes are MessageQueue and Message. The MessageQueue object is used to open or delete existing queues and create new ones. It is also used to send and receive messages. The Message object itself is used to encapsulate the data you want to send or receive into a message.
The following code snippet shows how to create a new message queue. First you want to check with MessageQueue.Exists if the queue already exists. If not, then you can create a new queue with MessageQueue.Create and provide the queue path plus if the queue is transactional or not. The queue path consists of three parts - the machine name, if it is a private queue or not plus the name of the queue. If you address a MSMQ instance on the same machine your code runs on, then you can use instead of the machine name also a dot. A public queue path uses "Machine name\Queue name" and a private queue path "Machine name\Private$\Queue name". The label of the queue is a user friendly name of the queue. Queues can also participate in transactions. MSMQ distinguishes between internal and external transactions. Internal transactions only encompass MSMQ. You start a transaction with a MessageQueueTransaction object, then send your messages with a MessageQueue object and at the end commit or abort the transaction. Aborting an internal transaction will roll back all send messages, meaning no message will be send. Messages can only be read/received after the internal transaction has been committed. External transaction means the component which sends the messages to a queue is registered in COM+ and participates in a COM+ transaction. In this case you use the COM+ transaction controls which itself use the MSDTC "Distributed Transaction Coordinator". The MSDTC will commit or abort the transaction. Otherwise internal and external transactions behave the same way. You can us internal or external transactions only when the queue has been marked as transactional. If the queue has been marked as transactional you can send only transactional messages and if it has been marked as "not transactional" then you can only send non transactional messages.
// check to make sure the message queue does not exist already
if (!MessageQueue.Exists(QueueName))
{
// create the new message queue and make it transactional
MessageQueue MQ = MessageQueue.Create(QueueName,true);
// set the label name and close the message queue
MQ.Label = LabelName;
MQ.Close();
}
The next code snippet shows how to delete an existing queue. First you check with MessageQueue.Exists if the queue exists then you delete it with MessageQueue.Delete. Message queues have also windows security ACLs assigned. This allows you to control access to queues through standard windows security. The security for queues can be set through the "Computer Management" interface by bringing up the properties window of a queue. If you do not have the right to delete the queue then MessageQueue.Delete raises a MessageQueueException exception, which for example is handled in the code snippet below.
// check to make sure the message queue does exist
if (MessageQueue.Exists(QueuePath))
{
try
{
MessageQueue.Delete(QueuePath);
}
catch (MessageQueueException)
{
MessageBox.Show("You do not have the rights to delete the queue.");
}
}
You can also enumerate a list of all message queues present on a MSMQ instance. To get a list of public queues you call GetPublicQueues, GetPublicQueuesByCategory, GetPublicQueuesByLabel or GetPublicQueuesByMachine on the MessageQueue class. To get the list of private queues you call MessageQueue.GetPrivateQueuesByMachine. The method names are self explanatory. All of them return an array of MessageQueue objects which you then use to obtain information about each queue. The code snippet below gets the list of private queues and then loops through each to get the queue name and label and if the queue is transactional or not.
// get the list of message queues
MessageQueue[] MQList = MessageQueue.GetPrivateQueuesByMachine(MachineName);
// check to make sure we found some private queues on that machine
if (MQList.Length >0)
{
// allocate a string array which holds for each queue the name, path, etc.
string[,] MQNameList = new string[MQList.Length, 3];
// loop through all message queues and get the name, path, etc.
for (int Count = 0; Count < MQList.Length; Count++)
{
MQNameList[Count, 0] = MQList[Count].QueueName;
MQNameList[Count, 1] = MQList[Count].Label;
MQNameList[Count, 2] = MQList[Count].Transactional.ToString();
}
}
A look how to send and receive messages with the .NET framework
You use a Message object to send a message to a queue. First you create a new MessageQueue object and pass along the queue path you want the message to be send to. Next you create a Message object and pass along the object which contains the data you want to send. When the message is send, this object will get serialized and stored in the message body. The default serialization object used is the XmlMessageFormatter, which serializes the object to XML. You can also use a BinaryMessageFormatter, which formats the object into binary format, or an ActiveXMessageFormatter which serializes in a format which is compatible with COM message queuing components. This formatter works with most primitive types and requires for objects the implementation of the IPersistStream interface. If you want to use a formatter other then the default one then you need to create an instance of it and assign it to the Formatter property of the message object. Then you set the properties of the message object as required and finally call the Send() method on the message queue object you created. At the end you close the queue by calling Close() on the message queue object. Here is a sample code snippet:
// create a message queue object
MessageQueue MQueue = new MessageQueue(MessageQueuePath);
// create the message and set the base properties
Message Msg = new Message(TheObject);
Msg.ResponseQueue = new MessageQueue(ResponseMessageQueuePath);
Msg.Priority = MessagePriority.Normal;
Msg.UseJournalQueue = true;
Msg.Label = Label;
// we want a acknowledgement if received or not in the response queue
Msg.AcknowledgeType = AcknowledgeTypes.FullReceive;
Msg.AdministrationQueue = new MessageQueue(ResponseMessageQueuePath);
// send the message
MQueue.Send(Msg);
// close the mesage queue
MQueue.Close();
The message object itself provides you with a lot of control about the message you are sending. You can set a user friendly label with the Label property. You can set the priority of the message with the Priority property using a value of the MessagePriority enumeration. If you want the message to be placed in a journal when received/read then set the UseJournal property on the message to true. The AcknowledgeType property provides you control over which acknowledgement you require using a value of the AcknowledgeTypes enumeration. For example setting it to FullReceive means you will get an acknowledgement if it has been received/read but also if the message is undeliverable or expired. The acknowledgement is sent to the queue specified by the AdministrationQueue property of the message. Via the TimeToBeReceived property you can specify by when the message needs to be received/read otherwise it will expire and be removed by MSMQ. You don't set an absolute date/time but rather a time span using a TimeSpan object. There are many more properties you can set on the Message object. Please refer to the MSDN documentation for a complete list.
You can use MessageQueueTransaction to start an internal transaction. You create an instance of that class and call BeginTransaction(). For every message you send and want to be part of this transaction you pass along this transaction object in the Send() method. When done you call Commit() or Abort() on the transaction object. The messages you send as part of a transaction will only be available to read by the time you call Commit(). Don't forget to still call Close() on the message queue object. Using a transaction works only with queues which are marked as transactional. Here is a code snippet:
// create a message queue transaction and start it
MessageQueueTransaction Transaction = new MessageQueueTransaction();
Transaction.Begin();
// create a message queue
MessageQueue MQueue = new MessageQueue(MessageQueuePath);
// create the message and set the base properties
Message Msg = new Message(TheObject);
// send the message as part of the transaction
MQueue.Send(Msg, Transaction);
// commit the transaction
Transaction.Commit();
// close the mesage queue
MQueue.Close();
Reading a message will automatically remove it from the queue and if the message property UseJournal has been set to true a copy will be placed in the journal. You read messages by calling Receive() on the message queue object. This call is synchronous and blocks till a message is available. An overloaded version of Receive() allows to specify a time span, the time how long the call will wait to receive a message. The Receive() method returns a Message object. The Body property allows you to access the object which was stored in the message when sent. It is important to use the same formatter type when reading and sending the message or otherwise an exception will be thrown. For example, if you used a BinaryMessageFormatter when sending the message then you need to create a BinaryMessageFormatter object and assign it to the Formatter property on the message queue object before you call the Receive() method. The XmlMessageFormatter is not able to recognize which type has been serialized into XML. Therefore you need to set the TargetType property on the XmlMessageFormatter to the type you have stored in the message. Through this the XML formatter knows which type to create and de-serialize out of the message. For performance improvement Receive() reads by default only a handful of properties from the message. Accessing a message property which has not been read throws an InvalidOperationException exception. Before you call Receive() you set on the message queue object through the MessageReadPropertyFilter property which message properties you want to be read. Call MessageReadPropertyFilter.SetAll() if you want to read every property of the message. Here is a code snippet:
// open the selected message queue
MessageQueue MQueue = new MessageQueue(ListOfMessageQueues.SelectedNode.Name);
MQueue.MessageReadPropertyFilter.SetAll();
// the target type we have stored in the message body
((XmlMessageFormatter)MQueue.Formatter).TargetTypes = new Type[] { typeof(Order) };
try
{
// read the message from the queue, but only wait for 5 sec
System.Messaging.Message Msg = MQueue.Receive(new TimeSpan(0, 0, 5));
// read the order from the message body
Order Order = (Order)Msg.Body;
// close the message queue
MQueue.Close();
}
// no message present to read
catch (MessageQueueException)
{
MessageBox.Show(this, "There is no message in the queue at this time.");
}
The code snippet specifies a time span for how log to wait for a message. If no message is present within that timeout, then a MessageQueueException exception is thrown. You can also read messages asynchronously. First you register an event handler of the type ReceiveCompletedEventHandler with the property ReceiveCompleted on the message queue object. Then you call on the message queue object instead of Receive() the method BeginReceive(). BeginReceive() will return immediately and the event handler you registered will be called when a message is available for reading. In the event handler you then call EndReceive() which returns the message. When you call BeginReceive() you get an IAsyncResult handler back which you need to pass along when calling EndReceive() so the method knows which asynchronous read to finish. You can call BeginReceive() multiple times. In this case you are waiting for multiple messages and for each available message your event handler gets called. Your event handler stays active, so keeps still waiting for a message, even after calling Close() on the message queue object. This behavior is due to the fact that read and write handles to the message queues are cached for performance reasons. Set the MessageQueue.EnbaleConnectionCache property to false to disables the cache which will make sure that your event handler no longer listens for messages after you close your message queue object. Here is a code snippet for asynchronous reads:
// it is important to set this to false, otherwise the message receiver event
// handler keeps still active even after closing the message queue object
MessageQueue.EnableConnectionCache = false;
// open the selected message queue
MessageQueue MQueue = new MessageQueue(MessageQueuePath);
MQueue.MessageReadPropertyFilter.SetAll();
// the target types we have stored in the message body
((XmlMessageFormatter)MQueue.Formatter).TargetTypes = new Type[] { typeof(Order) };
// set the event handler to be called when the message has been received
MQueue.ReceiveCompleted += new ReceiveCompletedEventHandler(MessageEventHandler);
// start the receive message process; this call returns immediately
IAsyncResult MQResult = MQueue.BeginReceive(new TimeSpan(1, 0, 0), MQueue);
/// <summary>
/// event handler called when the message is ready to be read
/// </summary>
private void MessageEventHandler(object sender, ReceiveCompletedEventArgs e){
// get the message from the queue
System.Messaging.Message Msg = ((MessageQueue)e.AsyncResult.AsyncState).EndReceive(e.AsyncResult);
// process the order
Order Order = (Order)Msg.Body;
// start looking for the next message
IAsyncResult AsyncResult = ((MessageQueue)e.AsyncResult.AsyncState).BeginReceive(new TimeSpan(1, 0, 0), ((MessageQueue)e.AsyncResult.AsyncState));
}
When you call BeginReceive() you can also pass along some state information. This can be any object and in our code snippet above it is the message queue object. This way the event handler can get hold of the message queue object and then call EndReceive(). If you want to continue waiting for the next message then you need to call in the event handler again BeginReceive() on the same message queue object. BeginReceive() and Receive() always read the first message in the queue and remove it from the queue. You can use Peek() and BeginPeek() with EndPeek() to peek for the first message without removing it. MessageQueue.GetAllMessages() returns you a list of all messages in a queue without removing them from the queue. Here is a code snippet:
// open the message queue
MessageQueue MQueue = new MessageQueue(MessageQueuePath);
// set the properties we want to retrieve
MQueue.MessageReadPropertyFilter.Id = true;
MQueue.MessageReadPropertyFilter.Priority = true;
MQueue.MessageReadPropertyFilter.SentTime = true;
MQueue.MessageReadPropertyFilter.MessageType = true;
MQueue.MessageReadPropertyFilter.Label = true;
// get all the messages; does not remove the messages!
Message[] Msg = MQueue.GetAllMessages();
// create a string array to store the message information
string[,] Messages = new string[Msg.Length,5];
// loop through each message and get the info we need
for (int Count = 0; Count < Msg.Length; Count++)
{
Messages[Count, 0] = Msg[Count].Id;
Messages[Count, 1] = Msg[Count].Label;
Messages[Count, 2] = Msg[Count].MessageType.ToString();
Messages[Count, 3] = Msg[Count].Priority.ToString();
Messages[Count, 4] = Msg[Count].SentTime.ToString();
}// close the message queue
MQueue.Close();
Another way to obtain the list of messages without removing them from a queue is the method MessageQueue.GetMessageEnumerator(). It returns a MessageEnumerator enumerator which you use to move from message to message. If there is no message available it will wait the specified time span. Here is the code snippet:
// open the message queue
MessageQueue MQueue = new MessageQueue(MessageQueuePath);
// we want to retrieve all properties for the message
MQueue.MessageReadPropertyFilter.SetAll();
// get a message enumerator we can use to go through all the messages
MessageEnumerator Enumerator = MQueue.GetMessageEnumerator();
// loop through all the messages
while (Enumerator.MoveNext(new TimeSpan(0,0,1)))
{
// get a reference to the current message
Message Msg = Enumerator.Current;
}
// close the message queue
MQueue.Close();
The MessageQueue object provides you with a lot of control how to read and send messages. But sometimes it would be useful to get notified when a message has been sent to a queue. You can achieve that by having a windows service running in the background and receiving or peeking synchronously or asynchronously messages. There is another approach you can use, MSMQ triggers.
A closer look at MSMQ Triggers
To be able to use triggers you need to install the "Triggers" component of MSMQ and make sure that the "Message Queuing Triggers" windows service is running. You can create triggers through the "Computer Management", under the item "Services and Applications", "Message Queuing" and "Triggers". First you need to create a rule under the item "Rules". A rule specifies a condition and the action to take when that condition is met. If you don't specify a condition, then the action applies to all messages in a queue. Otherwise the action only applies to messages which meet the condition. You can create complex conditions like the message label needs to contain this string, needs to have this priority, etc. The action can be to invoke this COM object or run this executable.
So right click on the item "Rules" and select "New | Rule" from the popup menu. Give the rule a name and description and click next. On the next screen you define the condition. Select from the drop down box the condition, for example "Message Label contains" and enter in the "filter/value" box the value of that condition, for example the string the label needs to contain. Click on the add button to add the condition. You can add as many conditions as needed or you remove individual conditions with the "Remove" button. When the condition is built, or if you don't want to apply a condition, click on the Next button. The next screen defines the action to take when the condition is met. Select if you want to invoke a COM component or an executable. For the COM component you need to specify the ProgID and the method to be executed, for example the ProgID "MQProcessor.MessageQueueProcessor" and the method name "ProcessMessage". For an external executable to run you specify the full path and name of the EXE. With the Parameters button you add the information which gets passed on to the COM object or executable. Select the available parameter from the drop down box and click add. You can add multiple parameters, remove parameters and sort them with the up and down button. The list of parameters and their types must match your method signature if you use a COM object. For an executable this is the list of command line arguments passed along. When done click ok and ok again to save the rule. You can create as many rules as required and edit existing rules by double clicking on a rule or remove rules by right clicking on a rule and selecting "Delete" from the popup menu.
A rule does not specify to which queue it applies. That is done by creating a trigger. Under each queue you find an item called Trigger which allows you to specify a trigger for that queue. Under the item "Triggers" (under "Message Queuing") you see all triggers created on this MSMQ instance. Either way you create a new trigger by right clicking on the item "Triggers" and selecting "New | Trigger" from the popup menu. Give the trigger a name and select the processing type which can be either "Peeking", "Retrieval" or "Transactional retrieval". If you want this trigger to be active then check the "Enabled" checkbox". The "Serialized" checkbox results in a serialized processing, meaning messages are processed one by one in the order they arrive. Otherwise if multiple messages arrive at the same time multiple instances of your COM object or executable could be invoked. On the next screen, after clicking Next, you can select the rules which are associated with this trigger. The list on the left side shows the available rules. Through the attach button you can assign rules to this trigger (shown on the right side). Through the Detach button you can remove rules from this trigger. Through the Up and Down button you can order the rules. The rules are executed one by one in the order specified. Click Finish to save the trigger. You can create as many triggers as required and edit existing triggers by double clicking on a trigger or remove triggers by right clicking on a trigger and selecting "Delete" from the popup menu.
If you want to use a .NET type instead of a COM object, make sure that you assign to your type the Guid attribute and the ComVisible attribute. The message body passed along (when selected in the parameter list) is an array of bytes. In order to be able to read the object you have stored in the message body you need to create a Message object, create a MemoryStream using this array of bytes and then assign the memory stream to the BodyStream property of the message object. You need to set again the formatter to use through the Formatter property of the message object and if you use the XmlMessageFormatter you need to set again the type. Here is a code snippet:
[ComVisible(true)]
[Guid("CBA5E590-86F8-4e65-8D8D-F03E2DAD6461")]
public class MessageQueueProcessor
{
[ComVisible(true)]
public void ProcessMessage(object MsgBody,string MQPath,string RespFormatName)
{
try
{
// get the response message queue path from the response format name
string MQResponsePath = RespFormatName.Split(':')[1];
// open the respone message queue
MessageQueue MQueue = new MessageQueue(MQResponsePath);
// create a message out of the message body we got passed along
// so we can read the message body in the format originally sent
Message Msg = new Message();
Msg.BodyStream = new System.IO.MemoryStream((Byte[])MessageBody);
Msg.Formatter = new XmlMessageFormatter(new Type[] { typeof(Order) });
// gets the Order from the message body passed along
Order TheOrder = (Order)Msg.Body;
// send the order unprocessed to the response message queue
// specified by the received message (so by the message sender)
MQueue.Send(TheOrder);
// close the response message queue again
MQueue.Close();
}
// catch any exception to keep the MSMQ trigger service ok
catch(Exception)
{}
}
}
It is important to handle all exceptions. Any unhandled exception will result in the "Message Queuing Triggers" windows service to terminate. If your method signature does not match the parameter list specified in the rule/trigger then you will see an entry in the application event log. The source is set to "MSMQ Triggers" and the description will say that the action defined by the rule has not been invoked because the COM object is not registered. The message is a bit misleading. After you created your .NET type you need to register it as COM object using the "regasm" utility. So the type can be found and loaded you also need to install the .NET type in the GAC using the "gacutil" utility. As you develop and troubleshoot your .NET type it is best to first stop the "Message Queuing Triggers" service, then unregister the type as COM object and then to remove it from the GAC. Then register the type again as COM object, add it again to the GAC and finally start the "Message Queuing Triggers" service again. Without that sequence I encountered sometimes unexpected behaviors which cost me much time trying to debug my code without really having any issues. Create a batch file which you just run each time when you are ready to test and troubleshoot your .NET type. Here is an example:
net stop "Message Queuing Triggers"
regasm MessageQueueProcessor.dll /unregister
gacutil /u MessageQueueProcessor
regasm MessageQueueProcessor.dll
gacutil /i MessageQueueProcessor.dll
net start "Message Queuing Triggers"
If you need to debug your component, then attach the .NET debugger (through the menu "Debug | Attach to Process") to the process "mqtgsvc.exe". But only do it after you ran your component once so it recognizes the process also as .NET process. Otherwise it will not recognize your .NET component and you can't debug it.
Summary
Microsoft Message Queue server provides a powerful messaging framework. It takes care of the complexities of guaranteed message delivery and routing. It is a great enabler to separate the parts of your application which interact with the user and back-end processing. It can also be a great enabler for asynchronous processing of long running tasks or processes. MSMQ triggers are a very convenient way to get notified about new messages and to process them. The .NET framework has a comprehensive set of types to interact with MSMQ. It makes it very easy to send and receive messages, to create new and maintain existing queues and allows to add effortlessly transactional support.
The attached sample application (created in Visual Studio 2005, using MSMQ 3.0) shows how to send transactional and non-transaction messages. It also demonstrates how to synchronously or asynchronously receive messages and how to process these messages. The interface of the example is very simplistic but it provides a framework for an administrative interface. You can create new queues, view the list of existing queues, view the properties of existing queues and view all the messages of queues. It also provides a trigger component which you can use to process incoming messages. See the "readme.htm" file for more details.