I guess simply waiting on an asynchronous Receive from a message queue is
not enough to keep a Windows service alive? I've written a service whose
only purpose is to process a message queue. The OnStart method looks like
this:

protected override void OnStart(string[] args)
{
    // TODO: Add code here to start your service.
    _executionQueue = new
MessageQueue(Properties.Settings.Default.ExecutionQueuePath);
    _executionQueue.ReceiveCompleted += new
ReceiveCompletedEventHandler(ReceiveCompletedHandler);
    _executionQueue.BeginReceive();
}

I thought this would start a thread to wait on the I/O event and this would
keep the service going, but as soon as I start the service I get the error
telling me it started and then stopped ("no work to do" etc.). Should I
throw in a dummy timer? That seems like a waste of resources to me. Also, a
newsgroup search turned up a suggestion to run everything from a class and
in a "while (_keepRunningFlag) { ... }" loop. Ideas?

Never mind. I had an exception at startup because the account I was running
the service under didn't have permission to read the queue. Everything's
working fine now.

Glad you got it figured out.  As for the other issue ... how to keep the
thread going without "spinning" try a AutoResetEvent object.  It's a better
way to hold open other threads, and shut them down when desired, without
spinning.
Show quoteHide quote

Encoding to ISO-8859-1 problems
.NET property names and translation
.NET to x86
What's the new thing after ActiveX?
= operator doesn't work when matched against DateTime value in RowFilter