email article printer friendly get the code

Get a Handle on .NET Remoting
Download a sample app to experiment with .NET remoting permutations.
by Juval Löwy

Posted July 15, 2002

It's no wonder that .NET remoting baffles many developers. A remote application, which can accept calls in binary or SOAP format on either TCP or HTTP channels, must register the objects it exports and the channels it's willing to accept calls on. Plus, a client application must register the objects it wishes to access remotely and indicate the activation channel. In addition, you have three activation modes and multiple ways of creating remote objects.

Figure 1. Study the Solution

Remote objects can be either client-activated or server-activated, and the server-activated objects can be either singleton objects or single-call objects. Client-activated objects are activated similarly to the way objects are activated in the classic client/server activation model: When a client creates an object, it gets a dedicated object. A singleton server-activated object is shared by all clients, whereas a single-call object is newly activated with each client and disposed of at the end of the call. The client decides whether it needs a client- or a server-activated object, and the server decides whether it will activate a singleton object or single-call object. The client and server must agree on the transport protocol (TCP or HTTP), the port to communicate on, and the communication format (SOAP or binary).

Figure 2. Run the Client Project

You can either configure these details programmatically (with the ability to perform runtime decisions for maximum flexibility), you can use a configuration file at load time, or you can do a combination of the two. Download the sample app for a comprehensive demo of a remote application and a client. The sample demonstrates the various programmatic permutations and scenarios using a simple user interface, as well as how the host application and the client can easily share the server metadata. In a future download, I will provide the same demo application using configuration files instead of programmatic calls.

Figure 3. Activate the Server Object Locally

Open the RemotingDemo.sln solution. The solution contains a host server EXE assembly, a DLL class library, and a client EXE assembly (see Figure 1). The client requires the class library metadata to compile, so it has a reference to the Server assembly. Similarly, the host application requires the server metadata to register the remote object, so it too has a reference to the Server assembly. The server object displays its hosting app domain name in a message box, as well as the value of a counter, to indicate singleton/single-call state:

public void Count()
{
   Counter++;
   string appName = 
AppDomain.CurrentDomain.FriendlyName;
   MessageBox.Show("Counter value is " + 
Counter.ToString(),appName);
}

Set the client as the startup project, and run it (see Figure 2). Without registering, click on the "new" button. The client creates the object and calls the Count() method twice:

private void OnNew(object sender,EventArgs e)
{
   MyServer obj;
   obj = new MyServer();
   obj.Count();
   obj.Count();
}