從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是一個非常出色的架構，但在商業方面，這是一個失敗，畢竟，設計一個出色的產品然後束之高閣難免“不像話”。
.NET Remoting恰恰是這個戰略的犧牲品，雖然擁有與生俱來的優點，不過依然生不逢時。
<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />Enterprise Services
從一個很直接的感覺來說，Enterprise Services只是對於COM+的一個包裝，從使用方式和技術實現本身而言，和VB或者VC下使用COM+服務沒有本質的區別，而更多的只是在於多了一層託管代碼的包裝，讓.NET開發人員能夠比較順利的使用這些服務的功能。
相對於J2EE平臺上的應用服務器如BEA的WebLogic，IBM的WebSphere或者開放源代碼的JBoss，微軟是希望能夠在企業級應用之中分一杯羹，可是因爲先天不足的原因，在企業應用中需要的事務、負載平衡、故障轉移等等技術中的表現不是那麼盡如人意，至少缺乏非常清晰的應用服務器（Application Server）的概念，雖然微軟不止一次的強調操作系統本身就是一個應用服務器，一個IT信息的基礎結構。但是從開發人員實際的使用來看，這是一個“晦澀難懂”的產品。
雖然.NET Framework改變了很多東西，但是作爲企業級應用中最重要的支撐技術——事務和服務，並沒有得到同等程度的發展，我想這個也就是很多大型企業應用目前不選擇.NET的一個理由吧，畢竟從MTS——COM+——Enterprise Services，這一路走來微軟始終不是提供一個非常透明的機制讓開發人員去控制各個環節（可能和微軟一貫以來的策略有關，只是關心最廣泛的應用而不是最高端的應用），而.NET中的所謂企業服務，和競爭對手提供的相當的EJB還是有比較大的差距，這是一個日前的微軟無法解決的軟肋。
Web Service
從一開始，微軟就將其作爲“重頭戲”推出，並且饒有意思的增加了XML，然後那個“XML Web Services”就成爲了.NET戰略中一個非常重要的術語，就如微軟的白皮書所言“Microsoft® .NET 是Microsoft XML Web Services 平臺”，微軟通過.NET來改變現有的互聯網絡結構，“Windows正在走向過去”這樣的宣傳是在於希望各個子系統之間的通信完全基於Web Service，那樣的話，作爲Win32開發人員一直困擾的組建註冊，分發等等一系列問題都能夠得到解決，並且能夠用更多的語言更多的平臺去開發應用。
“一切皆是Web Service”，這是一個冒進的舉動，至少對於4年以前的世界，而這四年以來，雖然Web Service有很多很多的優點可以讓我們“歌功頌德”，但是不是“萬金油”，比如一直稱垢的性能和安全問題也阻礙了Web Service一統天下，於是其他分佈式應用架構在特定的領域依然能夠有自己的生存空間。
這一次，微軟高估了Web Service，雖然目前的.NET是實現XML Web Services最好的平臺，Visual Studio .NET也提供了從上至下的包裝，讓開發人員完全可以不關心協議的底層實現，比如SOAP，比如對象序列化，比如WSDL，因爲一切的一切都可以在IDE中自動完成。我們不否認因爲.NET，Web Service從概念已經走進應用，而WSE 2.0的出臺更加Web Service具備了互操作能力，不過依然無法改變開發人員的觀點，只有在企業外網應用集成或者內部異種平臺整合的時候才能夠體現出優勢，在於需要高度響應和服務支持的應用方面，Web Service只是一個臆造的神話。
ASP.NET
我們無法否認，這項技術對於開發人員而言是一個顛覆性的改變，從靜態的HTML到CGI再到ASP/JSP/PHP時代，我們都必須去了解HTML，瞭解HTTP，對於高水平的開發人員而言，需要掌握的還遠遠不止這個，在腳本橫行的時代，我們必須很清楚的去了解實現的各個細節，包括HTML，JavaScript，CSS，還有和服務器相關的Request、Response。最直接而言，開發人員必須嚴格控制所有HTML及其相關內容的產生，腳本帶來的只是一個相對於CGI層次更加高級的“自動化”罷了。
然後，ASP.NET將這一切完全改變，WebForm讓Web開發人員能夠和Windows開發人員一樣處理頁面事件，同時可以完全的訪問強大的.NET Framework類庫，而且預先編譯機制解決了ASP一直以來的效率低下問題。而在服務器端的設計，在原先ISAPI的基礎上從新實現了HttpHandler和HttpMoudle，從而爲開發人員提供了高度擴展的可能，而日前比較成熟的WebLog引擎.Text正是這些技術的經典之作。
XML Web Services的內置集成則使ASP.NET成爲Web Service應用的最好實現，日前市場上相當大部分的Web Service都是基於ASP.NET的，在這點方面ASP.NET已經遠遠超出Java社羣的技術，包括JSP，包括Struct，包括JSF還有其他相關的Web應用技術，在ASP.NET都能夠得到非常好的集成。
我們不可能否認這個事實，相當大一部分（我個人認爲是大部分）的開發人員轉向.NET是因爲ASP.NET，對於ASP開發人員而言，ASP.NET提供了更加強大的功能，很多在ASP中必須依賴組件技術來解決的問題比如文件上傳在新的平臺上已經成爲內置支持，當然更加重要的是依賴Visual Stuio.NET強大的集成開發環境能夠成倍的提高生產率。而另外平臺的開發人員轉向ASP.NET我想也是因爲彈性的設計及其便捷的開發，我相信沒有太多人會懷疑ASP.NET已經走在Web開發的最前沿。
當然，任何事情沒有絕對的完美，在.NET Framework 1.1(也就是.NET的第二個版本)之前，太多的Postback也是讓開發人員抱怨之處，而且採用WebForm的開發方式讓很多開發人員不是那麼容易的處理客戶端腳本，所有的事件實現都是依賴於ViewState，因此在低帶寬下的網絡應用，不斷地提交也讓有些用戶感到“惱火”。
這個世界沒有絕對的完美，但是會一點一點走向完美，也許ASP.NET 2.0就有太多東西值得期待。
ADO.NET
相信大家不會忘記ADO（ActiveX Data Object）,我想Windows上面數據庫開發流行它功不可沒，通過統一的接口來實現對於數據庫的訪問，從而屏蔽複雜的數據庫訪問協議。而到了.NET時代，ADO.NET進一步將數據訪問“進化”，不要以爲ADO.NET只是ADO的一個升級，在ADO的技術上提供了一個託管類庫，除了都是數據訪問框架，其他沒有太多本質的關聯。
雖然ADO.NET帶來的震撼遠遠不如其他技術，可依然有很多東西值得我們去欣喜，畢竟創新總是一件好事情，何況是這個最成功的軟件公司帶來的創新，那麼我們就來看看到底帶來了什麼：
1． 除了提供了傳統ADO的Connection,Command以外，我們意外的沒有看到Recordset這樣的對象，而是提供了DataReader用來處理向前滾動的數據訪問，最最重要的是加入了DataSet這樣的概念，因爲如此，我們能夠實現很多數據庫應用中需要的“Disconnected Application”，能夠實現“InProc-Database”，而這一切，通過DataSet能夠得到很好的解決。
2． 以更加透明的方式提供了數據庫連接池，同時開發人員能夠通過變成的方式控制具體的運行方式。
3． 提出DataAdapter，讓開發人員能夠以一種統一的方式去訪問異種數據庫，唯一的區別在於具體適配器的實現不同罷了。
4． “Typed Dataset”讓開發人員能夠非常方便的將DataSet 中的Table、Field映射到自定義類。
5． 對於XML提供了良好的支持，所有的DataSet都能夠非常容易的系列化或者反系列化成XML文檔。
當然ADO.NET不是萬能的，在數據持久層（Data Presistent Layer）方面的支持顯然不如Java，到現在爲止都沒有一個很好的O/R Mapping工具，而Java方面的Hibernate已經非常成熟，ADO.NET 2.0中的ObjectSapce也許能夠改變目前的現狀，就讓我們耐心去等待，雖然需要到2005年。