How can I subscribe to events exposed by a remoted object?

Published 28 April 04 09:34 PM

     Delegates require information about the type that the method is associated with in order to make a call.  In a single app-domain, this isn't a problem, because the server (the object firing the events) has access to the type information for the client (which has the event handlers) by way of the delegate.

     However, during remoting, the server most likely does not have any information about the client.  If you want events from the server to fire in the client app domain, then the client must derive from MarshalByRefObject.  This is required so that the server will call back into the client, as opposed to a copy of the client object that is passed to the server.

     A simple way to do this is to place a copy of the client assembly in the same directory where the server directory is.  While this will work, it is not an elegant solution, as it exposes the client type unecessarily.

     A more elegant solution (albiet more complex), is to have a single assembly that is referenced by both the client and the server.  This assembly will have a shim class which will expose methods that share the signature of the events that you want to shim.  The assembly will also provide an interface with methods that share the signature of the events as well.  The shim will then take a reference to the interface, and the methods will aggregate the call to the interface that was passed in (I recommend the constructor as the place to pass the interface implementation).

     Finally, the client object will implement the interface.  When subscribing to the events that the server exposes, attach the delegates to the methods on the shim, which will be passed your client object's implementation.

     It is also important to note that in order for this to work, the TypeFilterLevel property on the sink provider for the server needs to be set to TypeFilterLevel.Full.

Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# Andreas Häber said on April 29, 2004 7:58 AM:
Mike Woodring has a very nice example for this here: http://staff.develop.com/woodring/dotnet/#RemoteEvents
# Peter Drier said on May 19, 2004 4:04 PM:
Remoting events is very dangerous across machines. A dead/dying/slow client can very easily eat up a server's threadpool. Be careful.

Check this under the "Cross-process on multiple machines in a LAN" section:
http://www.thinktecture.com/Resources/RemotingFAQ/RemotingUseCases.html

Peter
# RebelGeekz said on December 28, 2004 4:54 AM:
[http://itpeixun.51.net/][http://aissl.51.net/][http://kukuxz003.freewebpage.org/][http://kukuxz001.51.net/][http://kukuxz003.51.net/][http://kukuxz005.51.net/][http://kukuxz002.51.net/][http://kukuxz004.freewebpage.org/][http://kukuxz007.51.net/][http://kukuxz001.freewebpage.org/][http://kukuxz006.51.net/][http://kukuxz002.freewebpage.org/][http://kukuxz004.51.net/][http://kukuxz008.51.net/][http://kukuxz009.51.net/][http://kukuxz005.freewebpage.org/][http://kukuxz006.freewebpage.org/][http://kukuxz007.freewebpage.org/][http://kukuxz009.freewebpage.org/]

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required

This Blog

Syndication

Page view tracker