.NET Remoting delivers on the promises of easy distributed computing by providing a simple, extensible programming model, without compromising flexibility, scalability, and robustness. It comes with a default implementation of components such as channels and protocols, but all of them are pluggable and can be replaced with better options without much code modification. Earlier, processes were used to isolate applications from each other. Each process had its own virtual address space, and the code that ran in one process could not access the code or data of another process. In .NET, one process can now run multiple applications in a separate application domain and thereby avoid cross-process communication in many scenarios. In normal situations, an object cannot access the data outside its application domain. Anything that crosses an application domain is marshaled by the .NET runtime. Not only does .NET Remoting enable communication between application domains, but it also can be extended across processes, machines, and networks. It is flexible in the channels and formatters that can be used and has a wide variety of options to maintain state. Though .NET Remoting provides the best performance and flexibility, it too suffers from some vital pitfalls.
The following are the problems with .NET Remoting:
- .NET Remoting works best when assemblies that define the types that are used to integrate are shared. .NET Remoting works fairly well if there is full control over both ends of the wire. Therefore, it works well in an intranet where you have complete control of the deployment, the versioning, and the testing.
- Practically, .NET Remoting is proprietary to .NET and works seamlessly to exchange data between two .NET applications. It is deeply rooted in the common language runtime (CLR) and relies on the CLR to obtain metadata. This metadata means the client must understand .NET in order to communicate with endpoints exposed by .NET Remoting.
- .NET Remoting requires a big leap between programming at a high level and dropping down into the infrastructure. It’s pretty easy to code .NET Remoting with the available components, but if you want to start learning about adding your own transports, the level of complexity increases. .NET Remoting gives you finer-grained control on each architectural component but also requires a deep knowledge of its architecture.
- .NET Remoting suffers from the issues of load balancing because it is not intelligent enough to shift a request from a busy application server to one that is not as busy.