This documentation is archived and is not being maintained.

Windows Communication Foundation to Message Queuing

Download sample

This sample demonstrates how a Windows Communication Foundation (WCF) application can send a message to a Message Queuing (MSMQ) application. The service is a self-hosted console application to enable you to observe the service receiving queued messages. The service and client do not have to be running at the same time.

The service receives messages from the queue and processes orders. The service creates a transactional queue and sets up a message received message handler, as shown in the following sample code.

static void Main(string[] args)
    if (!MessageQueue.Exists(
           ConfigurationManager.AppSettings["queueName"], true);
        //Connect to the queue
        MessageQueue Queue = new 
    Queue.ReceiveCompleted += 
                 new ReceiveCompletedEventHandler(ProcessOrder);
    Console.WriteLine("Order Service is running");

When a message is received in the queue, the message handler ProcessOrder is invoked.

public static void ProcessOrder(Object source,
    ReceiveCompletedEventArgs asyncResult)
        // Connect to the queue.
        MessageQueue Queue = (MessageQueue)source;
        // End the asynchronous receive operation.
        System.Messaging.Message msg = 
        msg.Formatter = new System.Messaging.XmlMessageFormatter(
                                new Type[] { typeof(PurchaseOrder) });
        PurchaseOrder po = (PurchaseOrder) msg.Body;
        Random statusIndexer = new Random();
        po.Status = PurchaseOrder.OrderStates[statusIndexer.Next(3)];
        Console.WriteLine("Processing {0} ", po);
    catch (System.Exception ex)


The service extracts the ProcessOrder from the MSMQ message body, and processes the order.

The MSMQ queue name is specified in an appSettings section of the configuration file, as shown in the following sample configuration.

    <add key="orderQueueName" value=".\private$\Orders" />

The queue name uses a dot (.) for the local machine and backslash separators in its path.

The client creates a purchase order and submits the purchase order within the scope of a transaction, as shown in the following sample code.

// Create the purchase order
PurchaseOrder po = new PurchaseOrder();
// Fill in the details

OrderProcessorClient client = new OrderProcessorClient("OrderResponseEndpoint");

MsmqMessage<PurchaseOrder> ordermsg = new MsmqMessage<PurchaseOrder>(po);
using (TransactionScope scope = new TransactionScope(TransactionScopeOption.Required))
Console.WriteLine("Order has been submitted:{0}", po);

//Closing the client gracefully closes the connection and cleans up resources

The client uses a custom client in-order to send the MSMQ message to the queue. Because the application that receives and processes the message is an MSMQ application and not a WCF application, there is no implicit service contract between the two applications. So, we cannot create a proxy using the Svcutil.exe tool in this scenario.

The custom client is essentially the same for all WCF applications that use the MsmqIntegration binding to send messages. Unlike other clients, it does not include a range of service operations. It is a submit message operation only.

[System.ServiceModel.ServiceContractAttribute(Namespace = "http://Microsoft.ServiceModel.Samples")]
public interface IOrderProcessor
    [OperationContract(IsOneWay = true, Action = "*")]
    void SubmitPurchaseOrder(MsmqMessage<PurchaseOrder> msg);

public partial class OrderProcessorClient : System.ServiceModel.ClientBase<IOrderProcessor>, IOrderProcessor
    public OrderProcessorClient(){}

    public OrderProcessorClient(string configurationName)
        : base(configurationName)
    { }

    public OrderProcessorClient(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress address)
        : base(binding, address)
    { }

    public void SubmitPurchaseOrder(MsmqMessage<PurchaseOrder> msg)

When you run the sample, the client and service activities are displayed in both the service and client console windows. You can see the service receive messages from the client. Press ENTER in each console window to shut down the service and client. Note that because queuing is in use, the client and service do not have to be up and running at the same time. For example, you could run the client, shut it down, and then start up the service and it would still receive its messages.

This sample requires the installation of Message Queuing. See the installation instructions in Message Queuing.

To setup, build, and run the sample

  1. Ensure that you have performed the One-Time Set Up Procedure for the Windows Communication Foundation Samples.

  2. To build the C# or Visual Basic .NET edition of the solution, follow the instructions in Building the Windows Communication Foundation Samples.

  3. To run the sample in a single-machine configuration, follow the instructions in Running the Windows Communication Foundation Samples.

To run the sample across machines

  1. Copy the service program files from the \service\bin\ folder, under the language-specific folder, to the service machine.

  2. Copy the client program files from the \client\bin\ folder, under the language-specific folder, to the client machine.

  3. In the Client.exe.config file, change the client endpoint address to specify the service machine name instead of ".".

  4. On the service machine, launch Service.exe from a command prompt.

  5. On the client machine, launch Client.exe from a command prompt.

See Also

© 2007 Microsoft Corporation. All rights reserved.