Patrick,

Sounds like you've discovered the method that remoting services uses
to maintain it's connection.  Without lifetime management, the runtime
would not be able to know when it's "safe" to tear down the expensive
connection between the app-domains.  While this method is (IMHO) nicer
than the ref-counting method used in COM+, it does present some
limitations; of which you have discovered.  If you have a class-factory
creating new objects to "clients", you would most definitly not want
them to persist forever.  (In this case, memory would never be relased,
even when the "client" disconnects!)  We ran into a a simliar (but
different ... aren't they always that way?) design hurdle with a recent
project for a client of ours.  We had a "client" (I'm using the terms
loosely, as in the case of events, the client actually acts as a server
when the callback is invoked.  Anytime I refer to the client, I'm
meaning the application you wish the other process to invoke delegates
on.)  application that we wanted to be aware of the "server" process'
state.  It needed to re-register the callbacks upon a disconnection
(the other machine was power cycled, network problems...or *gasp* a
blue screen on the server...but that never happens) and thus needed to
"monitor" the connection.  What we did was setup a ping method on the
"server", which would do nothing more than turnaround and invoke a
delegate on the "client".  If we did not get a callback within some
reasonable threshold of time, we'd terminate our remoting channel,
reconnect to the "server" and register our callbacks again.  Something
like this:

Client-->Calls Ping method on server-->Waits...
Server-->Invokes callback on client
Client--<Starts process over again

This allowed us to know when the callback stopped working, as
(depending on the remoting confiuration) you could actually get a "new"
object from the "server" if your lifetimeservices timeout was reached.
Also, we ended up having to programatically control remoting in lieu of
the [app].config file, as you do not have the ability to explicitly
control the channel when using config files to set things up.

I would also examine the thread sync handles
(system.threading.waithandle) to wait for the server to reply within
the "worker thread" in the client!
Hope this helps.

         -- Ryan Berry

It sounds like you have an SAO which is raising events. Is there a reason
you don't want to implement this as a singleton that lives forever?

Ken