I've used MSMQ many times in the past. However, it's always been on my own systems, so I always exhibited the programmer's virtue of laziness and assume that I have correctly created the message queue and set its transactional state to what I expect it to be, and write my program accordingly.
However, this time I'm writing code that will set the standard for other programmers' work, and I don't maintain the infrastructure myself, so I thought I'd be thorough and do things like check for the existence of the queue and check to see if it was created to be transactional and behave accordingly. This all worked perfectly in my local development environment with its local queues.
But when I went to test the installation in the QA environment, I ran into all kinds of trouble. Specifically, all the properties and methods I was trying to use, with the exception of Send(), were throwing exceptions. 6 hours, lots of Googling, and 5 bodies later, I discovered the problem.
The functionality available in the MessageQueue object changes based on whether the queue being specified is local or remote, and which of the many queue path syntax you use. If you can't code for a specific environment (e.g., if the queue path is a configurable value) there is no way of knowing what functionality is available at run time other than trying to use a method or property and trapping the resulting exceptions.
This behavior is so incredibly bad in an infrastructure mechanism that it never occured to me that it would be coded this way, so I didn't even think of hitting the documentation of each failing method and property to see if it was actually available in any given context until I had exhausted every other possibility and scenario. And there were no googled pages that led me to conclude that that would be a good thing to do, despite other people obviously having the same problem.
So I'm putting this out there to prevent others from going through the same thing.
As an aside...
index -> indices
syntax -> syntices?