从 COM(Component Object Model) 时代到 DCOM(Distributed COM) ，微软扮演了一个推动者的角色。如果说 COM 提供了一个 Windows 平台上的对象通讯技术，并且逐渐成为应用程序之间彼此通讯及互动的技术主流，那么 DCOM 则是解决了计算机的通信和互动技术。
COM 的着眼点是在于同一台计算机上不同应用程序之间的通讯需求，跨到另外一台计算机之外，就不是一开始 COM 所设想到的领域。所幸跨程序的通讯和跨计算机的通讯差异仅在于通讯协议的处理 ( 也就是定位问题 ) ，对于数据交换上型别差异的处理并不会因此而有区别。所以要让 COM 的环境能更进一步延伸到跨计算机的领域，只要妥善解决计算机定位的需求，就有机会克服。同样幸运的是， COM 在一开始的设计中完全不去碰触跨计算机的问题，使得要在 COM 的架构之上再架上一层跨计算机的处理环境并不会去破坏到原本的架构。于是 COM 的网络延伸版本 DCOM(Distributed COM) 就此出现，专责让 COM 组件可以在网络环境下持续提供服务。 DCOM 最主要处理的是两个议题，第一个议题是网络通讯能力，第二个议题则是权限的问题。之前 COM 是在同一台计算机中找特定的组件，而 DCOM 则要更进一步去找网络上的某台计算机，之后沿用 COM 的机制找到计算机上的组件。
到了 .NET 当中，跨计算机的问题同样也需要对应的技术进行处理， .NET Remoting 就是一个对应于 DCOM 的技术，它让存活在不同应用程序域 (AppDomain ，一个 .NET 中的新概念 ) 、不同执行程序、以及不同计算机上的对象能够顺畅的进行沟通协作。在累积了长期以来分布式应用的经验之后，微软没有理由把东西设计的更难用。从某种意义来说， .NET Remoting 提供了比过去更易于使用的开发架构，用来来支持跨计算机的沟通作业，省却开发人员建立分布式应用程序时必须花费的心力，不过这样一个“出色”的分布式应用应用框架并没有得到本来应该得到的“待遇”。相对于 Java 的 RMI 而言，它更加简单同时保持设计方面的弹性，同时摈弃了 DCOM 的一些缺点，在对于一个前后端必须以有状态紧密结合方式进行互动作业，同时又期望呼叫和数据交换的动作上能以最有效的方式进行的环境而言， .NET Remoting 是一个比较恰当的选择方案。
可是问题在于微软本身对于 XML Web Services 的狂热推崇让 .NET Remoting 迷失了本来属于它自己的阵地，也就是说 XML Web Services 的过火让 .NET Remoting 忘记了自己应该承担的角色，于是在开发者眼中成为了一个“可有可无”的作品，至少对于很多开发人员而言，在需要创建分布式应用程序的时候首先考虑的是 XML Web Services ，而在于企业内部应用，特别是在可以控制服务器和客户端平台的情况下（比如完全基于 .NET 平台的应用）， Web Service 因为效率等等各个方面的原因并无法体现出优势。从技术本身来讲， .NET Remoting 是一个非常出色的架构，但在商业方面，这是一个失败，毕竟，设计一个出色的产品然后束之高阁难免“不像话”。
