Callbacks through delegates via interface

So, the best thing to do is to have an intermediary MarshalByRef object that is part of your common assembly that passes on the server-raised event to your client. This intermediary MBRO will consist of an event and a method called something like LocalEventHandle (which will need a signature compatible with your server event). LocalEventHandle just raises the intermediary's own event.

Conceptually, when your client starts, instead of registering a method directly with your server's event, the client will create a new intermediary, register the client method with the _intermediary's_ event, and then register the intermediary's LocalEventHandle method with the server's event. Now, when the server's event raises, the delegate will attempt to invoke the LocalEventHandle method. This is an MBRO method, so the invocation will get sent back to your client, where the appropriate intermediary instance will handle it. This intermediary instance will then raise its own event, invoking your client's method. This solution gets rid of both the client executable dependence you mentioned, and the requirement for the client to inherit from MarshalByRefObject

Below is a code sample that I used in one of my own applications (I was auto refreshing a TreeView control). In my case, all the events had no parameters, but you can imagine them with whatever parameters your event needs. This whole approach is outlined in Ingo Rammer's book "Advanced .NET Remoting", which is a great resource for the .NET Remoting developer.

namespace RemotingForumCommon
{
public delegate void RefreshDelegate();

public class RefreshEventWrapper : MarshalByRefObject
{
public event RefreshDelegate LocalRefreshEvent;

public void LocallyHandleRefreshEvent()
{
LocalRefreshEvent();
}

public override object InitializeLifetimeService() // Make sure the object exists "forever"
{
return null;
}
}
}

RobbyBryant at 2007-8-30 >