It's pretty obvious that MSMQ is a bit of a dark art out there. People know it exists, everyone knows someone somewhere that knows a guy who once did something with it, and like practitioners of esoteric arts, the technology is looked upon with distrust. In fact to the point that I see team after team recreate, usually poorly, the infrastructure for a true transactional queuing system, almost always defaulting to some SQL Server implementation.
Let's start with this simple axiom: DO NOT BUILD YOUR OWN QUEUING SYSTEM UNLESS THAT'S WHAT YOU ARE HIRED TO DO!
By the time you get it designed, debugged, and actually working you'll find that you've just spent your entire dev budget on something that probably doesn't even have half the real features of MSMQ (or any other vendor product). And I am not talking about little used fringe cases you don't need. I am talking about core infrastructure requirements for asynchronous communication infrastructure: Poison message detection, scale out, manageability tools, WMI and monitoring, QoS, and on and on...
Personally I think that the reason that people shy away from MSMQ is simple and clear: the documentation sucks, real working samples are rare, the features have quirks that are not always known, and lastly asynchronous message based solutions are hard. Well, I cannot fix the last item, hard is hard and unless you know how to design a Saga based solution you're going to have trouble. But the others are not hard, they just need explaining and simple working solutions to show how it works. With that being the case I am going to show the most basic of systems, a client and a server leveraging WCF with MSMQ. Attached to this blog is a very simple application that allows a client to fire and forget a WCF message and a service to activate and transactionally process it. I believe that this code and configuration should be clear enough (there's little to it!) and should "just work". Just make sure that you have MSMQ installed on your machine and run Visual Studio in elevated admin mode (so you can create MSMQ objects on your first run).
I have downloaded this zip and it doesn't even compile (on VS2010 or 2012) - firstly the service reference of "Client.Servcie" (yes that is the spelling) is having problems with namespaces - error =
Error 2 The type or namespace name 'Client' does not exist in the namespace 'Client.Client' (are you missing an assembly reference?) C:\Downloads\MSMQ Example\MSMQ Example\Client\Service References\Client.Servcie\Reference.cs 23 56 Client
To fix the above issue I did the following:
1) Threw away service reference in client (may need to copy & reinsert app.config servicemodel info as you will need that and the delete cleans that out [in vs2012 anyway] ).
2) Changed client app.config to use the "Contracts.IServiceProcessor" interface (not the one in the dodgy web reference)
3) Utilised ChannelFactory in Program.cs client code to consume interface via the following code (will need a "using Contracts;" line at top of program.cs also):
Console.WriteLine("Press enter to call service...");
var id = Guid.NewGuid();
Console.WriteLine("Sending message: " + id);
ChannelFactory<IServiceProcessor> oCF = new ChannelFactory<IServiceProcessor>("NetMsmqBinding_IServiceProcessor");
IServiceProcessor oSP = oCF.CreateChannel();
Console.WriteLine("Press enter to exit...");
Does also mean you no longer need to worry about tweaking the interface and forgetting to update the service reference if you wish to take this forward.
Sorry should have been signed in to allow you to respond to me - Paul.
No one here can repro any issues that you describe (probably a tooling version/differnce with our standard kits and what you have running). Feel free to hit me up directly if you want to discuss 1:1. Regardless, you appear to of worked around any issues.
Well, not that anyone cares, but your sample (inside of the zip file) does not compile out of the box, due to spelling errors.