|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
Asynchronous programming in a remoting scenario is identical to asynchronous programming in a single application domain or context, with the exception of configuration and the requirements of .NET remoting itself. For a complete sample using .NET remoting and synchronous and asynchronous delegates, see Remoting Example: Asynchronous Remoting.
Just like single-application domain asynchronous programming, using asynchronous programming in a .NET remoting scenario means:
The caller decides whether a particular remote call is asynchronous.
Remote types do not have to explicitly support asynchronous behavior by their clients.
The runtime enforces complete type safety.
You must use the System.Threading objects appropriately to wait or synchronize your methods.
However, in an application that calls across application-domain or context boundaries, .NET remoting requires you to configure the client application so that it may receive remote calls from the server (this is done by specifying a port of "0" on the client channel.) The reason for this requirement is once an asynchronous call is made there is no way to retrieve the results of the call without allowing the server to call back to the client.
The client does not need to extend MarshalByRefObject or configure any remote type itself, but otherwise must follow the same rules as any remote type intended to be a server:
The callback method must be an instance method. Static method calls are not remoted..
A channel must be registered to listen for the callback function.