.NET Remoting是.NET平台上允许存在于不同应用程序域中的对象之间进行通讯的基础设施。调用对象被称为客户端，而被调用对象则被称为服务器或者服务器对象。简而言之，它就是.NET平台上实现分布式对象系统的框架。
传统的方法调用是通过栈实现，调用方法前将this指针以及方法参数压入线程栈中，线程执行方法时将栈中的参数取出作为本地变量，经过一番计算后，将方法的返回结果压入栈中。这样我们就完成了一次方法调用。
基于栈的方法调用在同一个应用程序域中很容易实现，但是如果要调用的方法所属的对象位于另一个应用程序域或另一个进程甚至是不同机器间，这个时候怎么办呢？我们知道，应用程序域之间是无法共享同一个线程栈的，此时我们将转而使用另一种方法调用机制——基于消息的方法调用机制。在客户端通过代理对象将原先基于栈的方法调用信息封装到一个消息对象中，再根据需要将这些消息对象转化成某个格式的数据流发送到远程对象所在的的应用程序域中。
当经过格式化的消息到达服务器后，首先从中还原出消息对象，之后在远程对象所在的的应用程序域中构建出相应方法调用栈，此时就可以按照传统的基于栈的方法调用机制完成方法的调用，而方法返回结果的过程则按照之前的方法反向重复一遍。个人理解就是将要发送的东西打包传递给另一个应用程序域的意思。这中间就有两个很重要的概念，Client Proxy，它是负责在客户端处理基于栈的参数传递模式和基于消息的参数传递模式之间的转换，而对应的Invoker的功能与之相反。
具体到我们的.NET Remoting框架上来说，这张图上客户端的Transparent Proxy与服务器端的StackBuilderSink分别扮演了Client Proxy与Invoker的角色。Remoting依靠这两个对象实现了基于栈的方法调用与基于消息的方法调用的转换，并且这一过程对于开发者是完全隐藏的，就是说开发者不用关心底层间到底怎么传递，这是它的一个好处。另外我们在这张图上可以看到很多的Sink，而所谓的Sink就是一个信息接收器，它接受一系列的输入信息，为了达到某种目的对这些信息做一些处理，然后将处理后信息再次输出到另一个Sink中，这样一个个的Sink串联起来就构成了一个Pipeline，而Pipeline模式则将一个个的处理模块相互分离，各自独立，然后按照需要将它们串联起来即可，此时前者的输出就会作为后者的输入。此时，每个处理模块都可以获得最大限度的复用。对于要传递的对象，设计者除了需要了解通道的类型和端口号之外，无需再了解数据包的格式。这既保证了客户端和服务器端有关对象的松散耦合，就是我们这上面说到的Sink和Pipeline的关系，同时也优化了通信的性能。这里兼谈了.net Remoting的好处，那么我们接下来就可以看看它的应用了；
.net Remoting作为一种一种分布式处理方式，主要应用在构建分布式应用程序上面，这两张图是我从MSDN上比较Webservice和.NET Remoting上拷下来的，就是说在HTTP channel i与 IIS 和 ASP.NET集合的应用上，通过.net Remoting就可以不用去建立自己的进程管理和安全机制，而且由于其需要客户端，我们用二进制格式化程序来实现互操作系，从而提高整体的性能。
因为.net Remoting是DCOM，也就是分布式组件对象模式的继承，最后我说一下我.net Remoting和DCOM的比较。它们的共同点是都是由微软推出，用于跨应用程序域之间的进程间通信的技术。而不同点主要有三个：
一是DCOM技术是基于COM架构而.NET Remoting主要基于.NET框架，这个从名字就可以看出来；
二是DCOM是基于专有的二进制协议，是不是所有的对象模型支持，因此在网络世界的大的缺点，缺乏一致性。
三是DCOM 是基于RPC协议而.NET Remoting可以使用TCP或HTTP协议，而这是市场标准协议，所以相对说来.NET Remoting应用更广一些。谢谢。