Become a certified reverse engineer!
This article covers the means of cross-process and cross-machine interaction of applications developed with .NET framework. This snippet provides you with an in-depth understanding of the remoting capabilities that are built into .NET framework. It'll present some scenarios in which .NET remoting can be employed, and includes a historical background on the progress and development of various remoting frameworks. This will get you started with your first remoting application by creating and configuring its corresponding server and client modules by using HTTP, TCP, and IPC channels. At the end, you'll be able to design and develop remotable components under a CLR context.
Remoting was typically used for accessing a server's resources at the beginning of the client/server era. Every file server or database is an implementation of some tactics that allow code to be executed remotely. Nowadays, the building of distributed applications makes it easy to distribute business logic among diverse machines to improve performance, maintainability and scalability. There are couple of other distributed architecture implementations introduced and used frequently, such as Web Services, COM ,COM+, DCOM, RMI, CORBA and EJB. The following explains the need for remoting technology and its advantages over other technology.
You'll typically encounter a heterogeneous combination of different platforms such as Windows, LAMP, Mac programming languages, C++, PHP, Cold Fusion, and frameworks. Those include .NET, or JAVA in a larger or mid-size enterprise. So, integration of these technologies could be a daunting task for system architects. Remoting technology like .NET Remoting, CORBA and SOAP are an absolute necessity in large-scale enterprise application integration, in order to build scalable applications.
Centralized business logic
One of the key scenarios for implementing remoting technology is the concentration of business logic on a central server. That considerably simplifies the maintainability and operability of large scale applications, because we have to update one single server rather a number of users separately. When a centralized architecture shares different applications, it reduces programming labor.
.NET remoting is a process of programs or components interacting across certain application domains. The communication between application domains can happen inside the same process, between processes on a single system, or between processes on different machines. It provides a faster method of communication between .NET applications on both the client and server side. All in all, .NET remoting is a perfect paradigm which is only on a LAN (intranet), not on internet. .NET framework provides a foundation for distributed computing- it replaces DCOM technology.
Remoting implementations typically distinguish between mobile objects and remote objects. Mobile objects provide the ability to execute methods on remote servers, passing parameters and receiving return values. Remote objects will always be located in a server, and only a reference to it passes around other machines.
The following figure depictes a simplified view of remoting technology. Whenever a client application holds a reference to a remote object, it's represented by a TransparentProxy object, which masquerades as the destination object. This proxy will allow all target object instance methods to be called upon it. Whenever a method call is placed to a proxy, it's converted into a message that'll pass through various layers.
It's a flexible and extensible framework that allows for different transfer mechanisms, such as HTTP and TCP, encoding (binary and SOAP), and security settings such as SSL and IIS security.
We can use it anywhere, such as in console applications, Windows applications, COM components or Windows services applications. .NET remoting enables us to work with stateful objects.
When we use remote objects, .NET automatically keeps track of where they originated. So, a client can ask one server to create an object and safely pass the parameters to another server.
Remoting in Action
Remoting classes can be found in the namespace System.Runtime.Remoting and its core classes can be found in mscorlib.dll. When using remote objects, both client and server must have access to the same interface definitions and serializable objects that are passed by value. That means at least three assemblies are needed for any .NET remoting project.
- General Assembly (Class library project): A shared assembly which contains the interface and serializable object.
- Server Assembly (Console application): iThe server side implementation of MarshalByRefObjects.
- Client Assembly (Console application): The general assembly methods implementations.
General Assembly (Interface Definition)
First, create a C# base class library project where you have to define the interface ICustManager, which will be implemented by the server. In this interface, you'll define a single method. getCust(), that returns a customer object to the caller:
public interface ICustManager
Customer getCust(int id);
Now, you need to define a customer that will hold the customer data. This class must be serialized because its object needs to be passed as a copy. Here, we're declaring the name and address, and calculating the present age:
public class Customer
public string Name;
public int Age;
public string Address;
Console.WriteLine("Customer Object Created......");
public int getAge()
return ts.Days / 365;
Finally, compile this class library project and its corresponding Rem_GeneralLib.dll file. It'll be in the bin folder, which will be referenced in the remoting server project.
Remoting Server Implementation
The remoting server application will be a console base application. On the server, you need to provide an implementation of ICustManager that'll allow you to load a customer from a fictitious database. This implementation will only fill the customer object with static data.
To implement the server application, first add the references from Rem_GeneralLib.dll and System.Runtime.Remoting.dll. Now add these following lines to the declaration:
After, you'll have to implement ICustManager in an object derived from MarshalByRefObject. The method getCust() will just return a dummy customer object. Finally, register an HTTP channel which listens on port 7861. This channel is registered in the remoting system, which will allow incoming requests to be forwarded to the corresponding object.
public class CustomerManager: MarshalByRefObject, ICustManager
Console.WriteLine("Customer Manager Object Created......");
public Customer getCust(int id)
Customer cst = new Customer();
cst.Name = "Ajay Yadav";
cst.dt = new DateTime(1982,10,9);
cst.Address = "India";
static void Main(string args)
The class CustomerManager is registered as a WellKnownServiceType, which allows the client to remotely call its methods. The URL will be "RemotingServer." Object mode is set to singleton, to ensure that only one instance will exist at any given time.
Service Consuming (Client Implementation)
The remoting client will connect the server and ask for a customer object. For the client, you also need to add references of System.Runtime.Remoting.dll, and compile the Gen_Remoting.dll file again.
Register the channel, you don't need to specify the port number because client side ports are assigned automatically. Create a proxy class that'll support IcustManager, which is passed in the activator class as a parameter. Enter the URL of the server. Finally, call the customer class method in order to populate the customer class data.
static void Main(string args)
HttpChannel chn = new HttpChannel();
ICustManager mgr = (ICustManager)Activator.GetObject(
Customer cust = mgr.getCust(101);
int age = cust.getAge();
After finishing the coding, compile the client project. Remember, first run the server project console application which will listen on port 7861, then start the client console application which will produce the following output.
Note: System firewall echoes an alert because initially, it won't allow any communication on port 7861 for security reasons. So allow an ad-hoc communication on port 7861.
Notice in the server console, it'll notify you that all of CustomerManager constructor is called, right after the displayed output in the client project:
We can also confirm whether the socket is created on port 7861 or not by entering the netstat command.
Become a certified reverse engineer!
This article is an introduction to .NET remoting, a distributed computing technology. We now know about the various aspects in which .NET remoting fits in and is applied. We dug deeper into remoting concepts, and their advantages in detail. We also learned an example of remoting technology by creating three assemblies which encapsulated general assembly, the server program and the client application.