Asynchronous Remoting
This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).
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.
See Also
Tasks
How to: Call the Methods of a Remote Object Asynchronously
Concepts
Issues with Calling Methods of Remote Objects Asynchronously
Remoting Example: Asynchronous Remoting
Configuration of Remote Applications