WCF leverages MSMQ’s HTTP communication when the netMsmqBinding’s queueTransferProtocol is set to Srmp or SrmpSecure.
MSMQ itself has a bunch of restrictions when delivering messages over the HTTP and HTTPS ports and the following is a partial check list to get it working:
- Under Control Panel, Programs and Features, Windows Features, Make sure that HTTP support is checked.
- When this is first checked, if there is a Default Web Site in IIS, the operating system creates a new virtual directory called MSMQ under the Default Web Site
- If you have deleted the Default Web Site or MSMQ previously you’ll have to create this IIS application manually and add the following Wildcard Script Mapping for the Path ‘*’
- Make sure Default Web Site uses port 80, otherwise no messages will be delivered.
- Make sure port 80 and/or 443 are open in the firewall
- If there is a NAT for the server hosting the queue, there should be a mapping entry under C:\Windows\System32\MSMQ\Mapping\SomeMapping.xml. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms701477(v=vs.85).aspx
- WCF NetMsmqListener requires queue names to include full service path (example: private$\ServiceApplication/ServiceFile.svc) in order to activate the queue reads, whereas the MSMQ Http cannot deliver to URLs in with Formatname containing slashes.
- The above queue will have the format name HTTP://servername/msmq/ServiceApplication/ServiceFile.svc but MSMQ cannot find the queue through the IIS handler.
- The solution is to host the IIS WCF service with an address that does not contain special characters (example: private$\ServiceQueue)
- WCF will be able to read from queue whenever mex endpoint is browsed, so a background service that pings the mex endpoint periodically is a workaround.