*Words of Wisdom From The Elder

On January 1st, 2009 I received a really nice email telling me I had been selected to be a speaker in the INETA speaker’s bureau.  If you are not familiar with INETA here is a quote from their web site:

INETA provides structured, peer-based organizational, educational, and promotional support to the growing worldwide community of Microsoft® .NET user groups.

What does this mean?  It means that if you run or participate in a .Net User Group that meets the requirements for INETA then you can request me to come speak at your group and INETA helps to get me there.  For me this is great as it means I get to visit some areas I haven’t gotten to visit before and bring some WCF, Smart Client, Visual Studio, talks to areas I would otherwise not get to visit.

A big thanks to INETA for selecting me and a big congratulations to the other 15 members who were selected, many of which I consider friends (you know who you are).

Hopefully me spending several minutes to write down a problem we recently ran into at work working with WCF and the NetMsmqBinding will save some of you a lot of time.  If you’ve landed on this page here is the error you might be seeing:

An error occurred while opening the queue:The queue does not exist or you do not have sufficient permissions to perform the operation. (-1072824317, 0xc00e0003). The  message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that the queue is available to open with the required access mode and authorization.

There are a lot of things that can cause this error and it isn’t very descriptive.  Recently we were trying to deploy a service into our test environment and ran across this error. 

The issue was with the endpoint address.  Let me explain.

Let’s pretend our test server was named “wcftest”.  We had also created a host record in DNS that resolved to our application and configured our service in a virtual directory.  Let’s pretend that it was something like “http://MyApp/services/Msmq.svc”.  Here is the service configuration we were using.

   1: <service behaviorConfiguration="MyAppServiceBehavior"

   2:              name="MyAppService">

   3:                 <endpoint address="net.msmq://myapp/private/services/Msmq.svc"

   4:                  binding="netMsmqBinding" bindingConfiguration="msmqBinding" name="msmq"

   5:                  contract="IMyAppService" />

   6:                 <endpoint binding="mexHttpBinding" bindingConfiguration="" name="wsdl"

   7:                  contract="IMetadataExchange" />

   8:             </service>

First we checked to make sure we had a queue on the server named:  services/msmq.svc.   We did.

Secondly we looked at all the permissions on the queue and on the MSMQ service and everything was good. 

Because we were using the name of the host we had configured and setup in IIS we thought the endpoint address of the service was suppose to have the alias name in it (MyApp).  Turns out this was the problem.  Switching the address to the server name fixed the problem.  The change is:

net.msmq://wcftest/private/services/Msmq.svc

Thinking about it, it makes sense based on how MSMQ works (computer name to computer name).  It just isn’t something that jumped out at us instantly because the service was working on a development box, BUT, only because it was configured with the name of the machine and no alias.  Aha!