So one of the new features that’s going to be introduced in V2.0 of the .NET Compact Framework (NETCF) is support for Message Queuing. I feel it is a much anticipated feature and there is quite some excitement about this feature in the developer community.


A very high level intro…

The System.Messaging namespace provides classes that allow you to connect to, monitor, and administer message queues on the network and send, receive, or peek messages. Message Queuing can enable things like Inter-application communication without the need for a live connections and it is especially well suited for environments where multiple applications communicate over unreliable connections.


The mechanism is quite simple

A sending application’s message is accepted and placed in a queue that is accessible by the receiving application.

A receiving application can connect to the queue at any time to retrieve messages that have been left for it, and send back messages through same mechanism


You can find more background information about Managed support for System.Messaging here.


Since we are a subset of an existing technology, I think it would be valuable in the next series of posts to let you guys know upfront what is not supported on the NETCF implementation of System.Messaging.

Well since the classes provided in the System.Messaging.dll are essentially managed classes that wrap the underlying native Message Queuing APIs much of what we can do is limited by the capabilities of Windows CE MSMQ. The following features are not available on NETCF System.Messaging (due to limitations of CE MSMQ):


n      Remote Queue Read.

n      Encryption.

n      Security based on Access Control List (ACL)

n      MQMail.

n      Transaction support limited to single message transaction.

n      Public Queues based on Active Directory.


Support for Message Queuing on the Compact Framework eases application development for some pretty interesting “occasionally connected device” scenarios which embodies majority of mobile applications being developed today. A typical scenario is a sales inventory application where, before leaving the office, the user synchronizes the PDA with Data (either using MSMQ or via a Web Service) getting an updated list of items available in the inventory store. While at the customer site, no reliable connection exists and Orders can be taken. The application sends the order back to the server in the office
(by simply putting this into an outgoing queue). As soon as the sales person gets back to the office (or anywhere network connectivity exists), the order is transferred to the tracking system in the office. Since Message Queuing is an Operating System service, this last step is independent of the application (It does not have to be running), the OS will ensure that the messages in the Queue get sent as soon as a network connection is available.


Over the next series of posts I’ll be showing some sample NETCF System.Messaging code snippets that demonstrate some of this newly introduced functionality.