從 COM(Component Object Model) 時代到 DCOM(Distributed COM) ，微軟扮演了一個推動者的角色。如果說 COM 提供了一個 Windows 平台上的對象通訊技術，並且逐漸成為應用程序之間彼此通訊及互動的技術主流，那么 DCOM 則是解決了計算機的通信和互動技術。
COM 的着眼點是在於同一台計算機上不同應用程序之間的通訊需求，跨到另外一台計算機之外，就不是一開始 COM 所設想到的領域。所幸跨程序的通訊和跨計算機的通訊差異僅在於通訊協議的處理 ( 也就是定位問題 ) ，對於數據交換上型別差異的處理並不會因此而有區別。所以要讓 COM 的環境能更進一步延伸到跨計算機的領域，只要妥善解決計算機定位的需求，就有機會克服。同樣幸運的是， COM 在一開始的設計中完全不去碰觸跨計算機的問題，使得要在 COM 的架構之上再架上一層跨計算機的處理環境並不會去破壞到原本的架構。於是 COM 的網絡延伸版本 DCOM(Distributed COM) 就此出現，負責讓 COM 組件可以在網絡環境下持續提供服務。 DCOM 最主要處理的是兩個議題，第一個議題是網絡通訊能力，第二個議題則是權限的問題。之前 COM 是在同一台計算機中找特定的組件，而 DCOM 則要更進一步去找網絡上的某台計算機，之后沿用 COM 的機制找到計算機上的組件。
COM+倡導一種新的設計概念，把COM組件提升到應用層，把底層細節留給操作系統，使COM+與操作系統的結合更加緊密。COM+的底層結構仍然以COM為基礎，但在應用方式上則更多地繼承了MTS（Microsoft Transaction Server）的處理機制，包括MTS的對象環境、安全模型、配置管理等。COM+把COM、DCOM和MTS三者有機地統一起來，同時也新增了一些服務，如負載平衡、內存數據庫、事件模型、隊列服務等，形成一個概念新、功能強的組件體系結構，使得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 是一個非常出色的架構，但在商業方面，這是一個失敗，畢竟，設計一個出色的產品然后束之高閣難免“不像話”。
.NET Remoting 恰恰是這個戰略的犧牲品，雖然擁有與生俱來的優點，不過依然生不逢時。