Such property is not available, due to the multithreading nature of the class
System.Messaging.MessageQueue
:
http://msdn.microsoft.com/en-us/library/system.messaging.messagequeue.aspx[
^].
You can thing of it as of some full-proof feature. Otherwise, what does it mean if you check up availability of the message at some moment of time and assign the result to, say, some Boolean or integer ("count") variable/member? During this operation, the only available message could be removed by some other thread, or some message could be added to the previously empty queue. Even if the thread synchronization operation is used on the queue operations, it can happen during assignment operations or somewhere else.
You can get the equivalent effect if you simply
peek a message (that is, get without removing from the queue) with some small
timeout:
http://msdn.microsoft.com/en-us/library/t5te2tk0.aspx[
^].
But this is not a really correct approach. Instead, you should review your code design the way not using message count at all. The technique is designed to be used in separate thread, which perform blocking calls, and, in particular, are put to the
wait state unconditionally, until a message becomes available. This is that very main blocking operation:
http://msdn.microsoft.com/en-us/library/829zyck7.aspx[
^].
—SA