Msmq and troublesome API experience
There is just one thing in the Msmq API that I hate.
If you try to send to a queue using the wrong transaction, it will silently not send you message, but give absolutely no error.
This is incredibly error prone, and has caused me quite a number of bugs.
If at all possible, API should never silently fail. In this case, the API should throw an explicit argument exception, saying that this transaction is not valid for this queue.
That would make things much simpler all around.
Comments
Man, this is an ENTERPRISE api (in some Microsofty way)
there are a number of things with system.messaging that bug me, but that's definitely one of them. the api explosion around reading messages is a real headache as well. another thing that gets to me is the need to set "this property is readable" properties before you inspect certain attributes of your queue or message. while i understand the need to do this, the way it's done is suboptimal to say the least.
have you looked at using WCF's msmq transport rather than system.messaging for raw msmq work?
Using the WCF msmq transport only add overhead & complexity that aren't really needed.
MSMQ and transactions wasn't something to look forward to when coding, and then WCF came along and takes the pain out of it.
I had a lot of fun making this little project. The transactions make MSMQ behave in a way that proves to be super useful. It's very durable to, you can turn the services on and off as you like, and when they come back on-line things keep processing. If anything goes wrong, the transaction blows up and keeps the message on the queue to be processed again. It's very hard for this system to fail to process the initial request (and there's contingency rules built in to decide when it's had enough).
I see this from a different angle, I've got to say using the WCF MSMQ transport removes overhead and complexity.
Oh, here's the URL for my project:
http://code.msdn.microsoft.com/duratrans