Abstract
This article shows how cross-process and cross-machine interaction of applications are developed with the .NET Framework work. This snippet especially provides you with an in-depth understanding of the remoting capabilities that are built into the .NET framework. It presents some scenarios in which .NET Remoting can be employed and includes historical background on the progress and development of various remoting frameworks. These pieces get you started with your first remoting application by creating and configuring its corresponding server and client modules using HTTP, TCP, and IPC channels. At the end of this, you will be able to design and develop removable components under the CLR context.
Why Remoting?
Remoting was typically used for accessing a server's resources at the beginning of the Microsoft client/server era. Every file server or database is an implementation of some tactics that allows code to be executed remotely. Nowadays the building of distributed applications is feasible to distributed business logics among Perse machines to improve performance, maintainability, and scalability. There are a couple of other distributed architecture implementations introduced and used frequently such as Web Services, COM, COM+, DCOM, RMI, CORBA, and EJB. The following point poses the need for remoting technology and the advantages of such inherent technology.
Cross-platform Communication
You will typically encounter a heterogeneous combination of various platforms, such as Windows, LAMP, Mac programming languages like C++, PHP, cold fusion, and frameworks for instance .NET, Java in a larger or mid-size enterprise. So, the integration of these technologies could be a daunting task for system architects. Remoting technology like .NET Remoting, CORBA, and SOAP is an absolute necessity in large-scale enterprise application integrations for building 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 need to update one single server rather than a number of users separately. When this centralized architecture is shared among various applications, it reduces the huge programming labor.
Remoting Architecture
The .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 format for communication between .NET applications on both the client and server side. All in all, .NET Remoting is a perfect paradigm that is only possible over a LAN (intranet), not the internet. In the .NET Framework, this technology provides the foundation for distributed computing; it simply replaces DCOM technology.
Remoting implementations typically distinguish between mobile objects and remote objects. The mobile objects provide the ability to execute methods on remote servers, passing parameters and receiving return values whereas the remote objects will always be located at the server and only a reference to it will be passed around among other machines.
The following figure depicts a simplified view of remoting technology. Whenever a client application holds a reference to a remote object, it would be represented by a TransparentProxy object, that masquerades as the destination object. This proxy will allow the entire target object instance methods to be called upon it. Whenever a method call is presented to the proxy, it will be converted into a message and the message will pass using various layers.

Remoting characteristics
- It gives you 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 this technology anywhere such as on console applications, Windows applications, COM components, or Windows services applications.
- .NET Remoting enables to work with stateful objects.
- When we use remote objects, the .NET automatically tracks where they originated. So a client can ask one server to create an object and safely pass this as methods parameters to another server.
Remoting in Action
The Remoting classes can be found in the namespace System.Runtime.Remoting and some of its core classes can be found in mscorlib.dll. When using remote objects, both the client and the server must have access to the same interface definitions and serializable objects that are passed by value. This leads to the general requirement that at least three assemblies are needed for any .NET Remoting project.
- General Assembly (Class library project): it represents a shared assembly that contains the interface and serializable object.
- Server Assembly (Console application): it contains the server-side implementation of MarshalByRefObjects.
- Client Assembly (Console application): this consumes the general assembly methods implementations.
General Assembly (Interface Definition)
For the first step, create a C# base class library project where you must define the interface ICustManager that will be implemented by the server. In this interface, you'll define a single method. gust(), which returns a Customer object to the caller as in the following.




Bhuvanesh MohankumarPosted Apr 23, 2016, 5:50 PM
.Net Remoting is explained good
Santhakumar MunuswamyPosted Jun 22, 2015, 3:28 PM
Thanks for nice article
Udaya kumarPosted Dec 11, 2014, 2:46 AM
Very thanks...
Arun YadavPosted Nov 4, 2014, 7:07 AM
this article defined and good described by demo . Congrats ajay sir, thankyou for keep posting good stuffs