Is there a way to determine if the lease has expired, and does it expire
immediately? A test I just did suggests that it doesn't. I killed my client
and allowed the server to attempt to raise another event. I got an exception
to the effect that the "machine had actively refused the connection". Is
there a neater way than just trap the exception when it occurs? Obviously,
in normal operation the client would tell the server that it was going away,
but what if it doesn't?
In my case, there will be quite regular communication between server and
client (when one is running), but to be on the safe side I override
InitializeLifetimeService. Would that cause a problem?
I think I can see a way to make this work for me, using your suggestion, but
bits of it just seem a little inelegant. For example, if this were a
listener then it would need to attach to another process and listen without
the other process being aware, and detach without upsetting the main
process. It would also not impact the main process performance because it
would listen asynchronously. I think of it like a recital. It doesn't affect
the performer whether there are one, ten or none listening. The recital
continues the same. That's really all I am trying to do here.
"Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxx> wrote in
> There is no solution that is going to get over the message coming in on
> a non-UI thread. It just complicates things when the implementation of
> the callback interface on the client is on the UI object itself. You are
> better off having a separate object on the client that derives from MBRO
> and then exposes events that other objects can respond to. Any calls from
> the server to the client which result in updating the UI will have to be
> marshaled from the callback to the UI thread.
> Regarding the server and the client being tightly bound, this is no
> more the case than when you use events. Yes, the server has a reference
> to the client, but with events, the same thing occurs.
> If the client goes away (in this case, the object implementing the
> callback interface, or the server, for that matter, since they both derive
> from MBRO), then the lease will expire, and the proxy on the other end
> will be invalidated.
> - Nicholas Paldino [.NET/C# MVP]
> - mvp@xxxxxx
> "Charles Law" <blank@xxxxxx> wrote in message
>> Hi Nicholas
>> Thanks for the reply. I think I have half done what you suggest already.
>> I have a class in the server that inherits from MarshalByRefObject. I
>> create an instance of that in the client, and then use it to sink events
>> raised by the server. By passing this object to the server on which to
>> raise its events, it seems that the server and client would be quite
>> tightly bound together though. If the client goes away without telling
>> the server (crashes), the server would try to raise events on an object
>> that doesn't exist, but where the reference is not nothing. Then what
>> would happen?
>> I'm not sure that solution gets over the UI thread issue either. The
>> event will always be on the wrong thread until it is marshalled to the
>> right thread, or BeginInvoke is used. I think I would have to do that in
>> any case.
>> "Nicholas Paldino [.NET/C# MVP]" <mvp@xxxxxx> wrote
>> in message news:upF73RO8IHA.3724@xxxxxx
>>> I would recommend against using an event in this situation. Rather,
>>> have a shared interface which represents the callback from the server to
>>> the client, and then implement an instance of that object on the client
>>> side, making sure the class derives from MarshalByRefObject. Then,
>>> expose a method on the service which takes an instance of this
>>> implementation and pass your MarshalByRefObject to that method on the
>>> This allows the service to call back into the client. Then, you can
>>> have that object raise events which other classes can respond to. I
>>> don't recommend calling back directly to say, the UI, because the calls
>>> will come in on threads other than the UI thread.
>>> - Nicholas Paldino [.NET/C# MVP]
>>> - mvp@xxxxxx
>>> "Charles Law" <blank@xxxxxx> wrote in message
>>>> I've read numerous articles and bits of code that purport to do this,
>>>> but I think there is a gap somewhere (quite possibly in my head).
>>>> I have a server, which is actually a Windows service. I also have a
>>>> client that needs to retrieve information from this service, but also
>>>> needs to receive events from it, when it (the client) is running. I've
>>>> done all the MBO stuff, and the client can pick up info from the server
>>>> at will. That was the easy bit.
>>>> Now, I want the service/server to be able to raise an event, and the
>>>> client to handle it. The sticking point seems to be: How do I raise the
>>>> event in the server? It seems to me that in order to do that I need a
>>>> reference to the MBO on which the event is to be raised. In my server I
>>>> Dim identifier As String = "MyServer"
>>>> Dim mode As WellKnownObjectMode = WellKnownObjectMode.Singleton
>>>> Dim entry As WellKnownServiceTypeEntry
>>>> entry = New WellKnownServiceTypeEntry(GetType(MyServerMBO), identifier,
>>>> But how do I get a reference to the MyServerMBO that is created?
>>>> I have tried making everything Shared, so that I don't need a
>>>> reference, but although I can see the RaiseEvent call being made, the
>>>> debugger steps right over it, indicating that there is nothing attached
>>>> to it, and the client never receives a call.
>>>> Have I missed something here?