A Simple Guide to .Net Remoting

A Simple Guide to .Net Remoting

By jamiemoffat

Remoting is .Net’s way to create and uses object instances on a remote machine, without any of the hassle of DCOM.

This guide provides a (very) quick guide to getting you up and running and calling across your network. Most of the examples that Microsoft provide use a console application to host your remote object, which wouldn’t be the way most of us will use the technology.

This tutorial will cover the most common hosting method, which is within IIS.

I haven’t gone too deep into all the settings that are available with .Net Remoting, I will cover those in a future article.

1) Create a C# class that inherits MarshalByRefObject: E.g.

public class myObj: MarshalByRefObject
{
     // ...
}

Add some classes, properties etc.

2) Compile it to produce myObj.dll

3) Now, the object needs to be hosted somewhere. The easiest way to do this is to host the object within IIS.

First of all though, we need to describe our object so it can be accessed. To this end, create a web.config file with the following text:

E.g.

 <configuration> 
  <system.runtime.remoting>
    <application>
      <service>
        <wellknown mode="SingleCall" type="myNamespace.myObj, myObj" 
                        objectUri="myObj.soap" />
      </service>
    </application>
  </system.runtime.remoting>
</configuration>

In this XML:

type ="myNamespace.myObj, myObj" is the full type name, followed by the assembly name.

On the Remote Server:

1) Create a directory called “myRemoteObject”. Create a Bin directory beneath it.

2) Create a new IIS virtual Directory called myIISObj that points to the myRemoteObject directory.

3) Place your compiled versions of myObj.dll in the myRemoteObject \Bin directory

4) Place the Web.Config file in the myRemoteObject directory.

On the Client:

In your application set a reference to the local object on your client machine. This allows he CLR to pick up the meta data of the object so that we can create the object remotely (There is another way to generate the meta data without needing the actual object on the client, a utility called SoapSuds.exe, but I leave that for you to read about )

Now we need a client.config file analogous to the web.config file, which tells the CLR how to access (ie. where to access) the remote object.

<configuration>
  <system.runtime.remoting>
    <application name="Client">
      <client url="http://andy2k/myIISObj">
        <wellknown type="myNamespace.myObj, myObj"         
                    url="http://andy2k/myIISObj/myObj.soap"/>
      </client>
      <channels>
        <channel ref="http" />
      </channels>
    </application>
  </system.runtime.remoting>
</configuration>

(Note: replace “andy2k” with the name of your remote server)

Now in the client code, simply create the object as usual but, first of all, load the config file.

//Load the Http Channel from the config file
try
{
    RemotingConfiguration.Configure("client.config");
}
catch{}

//instantiate the remote object on the server
//(this is really just a proxy object here)
myNamespace.myObj anObj = new myNamespace.myObj();

The .Net runtime picks up the fact that this is not a local object (because of the config file read in the previous line) and creates the object on the remote machine. You now access the object as if it was created locally, and .Net does the rest.

(if you’re not convinced, create a method in the class that simply returns a string representing the name of the local machine

Something like:

Public string getCompName()
{
    return System.Environment.MachineName;
}

that should convince you that the object has been created on the remote machine)

And there you have it – you’ve just created a remote object!