——談microsoft .Net戰略
四年的時間對於歷史而言只是滄海一粟，而對於一個商業公司而言，卻足以重生幾回。從微軟提出.net戰略到現在也接近四年了，而今的我們應該怎樣去看待.net四年走過的歷程，怎樣去評價.Net戰略。
從職業角度來講，過去的半年實在是瘋狂，絕對的瘋狂，至少我是這樣。其中有很多原因，但最重要的一個原因實際上是我們公司正在經歷的變遷。而今天所作的介紹從某種意義上可以說，許多人、尤其是我，度過了無數個不眠之夜、花費了無數心血來認真思考這場變革。但是從某種意義上講，正是這一變革，促使比爾·蓋茨在年初作出了重要決策。我們確實花費了全部時間來認真考慮新一代的互聯網會是什麼樣，怎樣把如此眾多的部分，包括我們已經做過的一些開發，完美地結合起來，繼續保持世界領先地位，成為100%的比爾·蓋茨時代。
微軟總裁兼首席執行官——史蒂夫·鮑爾默
.Net的激情起航
2000年6月22日，這是一個所有“微軟人”都應該記住的日子，因為從這一天起，微軟公司將下一場賭注，一場押上全部身家的世紀豪賭——這一天，比爾.蓋茨向全球宣布其下一代軟件和服務，即microsoft .net平台的構想和實施步驟。新一代的microsoft .net 家族產品和技術替代了此前“下一代Windows服務(ngws)”的提法，它涵蓋了幫助軟件開發商構建下一代互聯網服務和給予新一代智能互聯網設備強大功能的軟件。此外，微軟還宣布了基於.Net 平台的新產品計劃，其中包括新一代的微軟Windows操作系統、Windows dna服務器、微軟Office、msn互聯網網絡服務、visual studio開發系統。
這樣的決定對於當時已經全球領先的微軟而言，無疑是“押寶”，將未來十幾年內的發展押給了他們構築的.Net，當然也正是從那一刻開始，這家全球最大的軟件公司也會不會遺力的去推進這個“偉大的夢想”。
那時的.Net
什麼是.net？.net有什麼？有人也認為是微軟故意模糊概念，實際的.net是Windows dna(distributed network architecture)和com+的一個延續，在本質上沒有改變。雖然這樣的理解有時偏頻，但是問題是明顯的，我們不是那麼容易的理解“什麼是.Net”。
2000年微軟的白皮書這樣定義.net：microsoft? .net 是microsoft xml web services 平台。XML web services 允許應用程序通過 internet 進行通訊和共享數據，而不管所采用的是哪種操作系統、設備或編程語言。microsoft .Net 平台提供創建 XML web services 並將這些服務集成在一起之所需。對個人用戶的好處是無縫的、吸引人的體驗。
我們可以清楚的看到微軟對於.net的理解是XML web services的平台，一切皆是服務，下一代的internet應用將是依賴於web service來構建，microsoft .Net 平台由以下技術構成：
l .Net用戶體驗
l .Net基礎設施和工具
l .Net服務構造塊
l .Net設備軟件
用戶永遠是上帝，脫離用戶討論戰略沒有實際意義，為此除開倡導的平台核心技術以外，微軟還承諾對於個人用戶提供.Net用戶體驗，其中包括：
Windows .Net
msn .Net
用戶訂購服務
Office .Net
bcentral for .Net
visual studio .Net
從這些文字我們可以看出，微軟幾乎可以將自己的全部產品加上“.net”的字眼，但是那是不是因為著這就是“.Net”?
everything is .Net
大概是為了強化.Net在人們心目中的印象，
微軟此時開展了一場dotnetialization（.net化）運動，幾乎所有傳統的、創新的和虛構的產品都被打上“.Net”的標簽。
為了擴展.net戰略的宣傳，微軟將其很多仍使用傳統技術的產品都加上了“.net”字眼。最典型的莫過於2000年底發布的.net enterprise server系列。這套服務器軟件雖然打上了.net標簽，但與.Net技術沒有任何關系。
真正創新的思想是web service。微軟當時極力推動web service從概念走入應用的最核心。
此外，微軟還虛構了、或者至少是過早描繪了一些新的、以“.Net”命名的產品與服務。
一切都是.net，微軟這樣做的結果就是將.net這個品牌叫得路人皆知，而其實質概念則幾乎沒有人了解。除了提供一些開發工具的支持，其他方面的.net推進有點做作的感覺，更加實際的來說.Net戰略只是一個clr的平台，其他方面的概念解釋都讓人牽強。
迷惘
經過一年多的喧囂，.net已經漸漸熱起來，越來越多的人開始使用.net，至少開始關注這個平台，c#的正確發音已經盡人皆知。但是，看得出來，微軟自己對於.Net的態度已經發生了微妙的變化。原來的計劃太龐大，即使微軟這樣的巨人也無法掌控。前面的路應該怎麼走？微軟也產生了迷惘。
2001年5月31日office xp正式發布，它顯然不是“傳說”中的office.net。微軟強調這個xp版本加大的是“體驗”（experIEnce）及其網絡的整合，而“用戶體驗”和與網絡的融合都是“.net戰略”的一部分。但是，實質的改進有什麼呢？除了返璞歸真的平面圖形菜單（戲劇性的是這樣的界面成了日後眾多軟件界面模仿的對象），和內建支持了soap工具包及其聯機搜索能力，我們發現和當初預想的Office.Net有天壤之別。
office開發采取滾動方式進行，也就是在發布office xp之前，下一版office已經在開發中。據說部真的正在開發一個雄心勃勃的Office.Net。在這一激進的計劃中，所有的訪問都是通過web service來完成的，應用程序與網絡的融合史無前例。不幸的是，這個產品最終流產，並且直接導致一個副總裁的辭職。究竟是技術上太不現實，還是微軟意識到這個產品無法被用戶接受？我們已經不得而知。
如果說Office曾經太激進，那麼那些支持it應用基礎架構的應用服務器又是如何呢？在商業應用中的commerce server 2002，biztalk server 2002，content management server 2002等等，雖然在一定程度加上了.net framework的支持，但是感覺有點是被微軟強行聯姻的“親家”罷了，visual studio .net對於其開發的支持依然是一種有心無力的感覺，並且這寫服務器提供的並不是完整的托管類庫，很大一部分功能仍然需要通過com的方式來完成訪問。.net是一個龐大的戰略，但是在短短的時間內希望完成到一個新的平台的遷移不是那麼容易的事情，而此時.net enterprise server系列的2002版本雖然在一個.net的名頭下依然是一個服務器群集，但是根本無法體現出.Net曾經的設想。
此時的vs.net有點孤軍奮戰的感覺，畢竟和其他應用服務器的結合不是那麼盡如人意，並且在managed c++方面的表現也不足以作為系統級開發的利器，因此還是有些人在等待，而不會去考慮將已有的應用全部遷移到.Net平台上來。
所有這些情況，不僅體現了，同時也導致了微軟的困惑。一個技術概念，如果不能與切實可用的產品結合起來，就會變成空中樓閣。
對於用戶而言，最重要的是能夠實際帶來什麼，而不是僅僅帶來概念，經歷了那段迷惘，微軟對於.Net的理解終於“塵歸塵，土歸土”，穿過水花鏡月，一路堅定的走來。
務實
? 2002年7月24日，比爾?蓋茨在一個內部講話中承認說，2000年9月推出的.net企業服務器稱作.net“是有點草率”，也正是從這個時候開始微軟真正開始反思.Net戰略是否太過泛濫，是否超出了他們所能夠控制的范圍。
在反思中摒棄浮躁，在務實中前行，經過兩年時間的喧囂和反思，.Net正在一點一點地走進現實應用。
? 2003年4月25日，曾被命名為windows .net server的windows server 2003正式發布。Windows Server 2003此前曾四易其名，它是第一個內置支持.net framework 1.1的Windows操作系統，因此有資格戴上.net的標簽，但最終確定的名稱中並沒有包括“.Net”字樣，出乎很多人的預料。
同日，微軟發布了基於.net framework開發工具的第二個版本，也就是visual studio.Net 2003，經歷了一年的發展，2003版本終於被越來越多的開發人員所接受，除了修正了2002版本的一些細節性錯誤，在類庫方面也更加強健和良好的兼容。
也也就是從此刻開始，vs.Net成為一個最強大的開發平台，多語言集成的開發環境，開發人員不僅可以開發傳統的Windows應用，能夠開發web應用程序，同時在移動開發，企業級組件方面都提供了良好的支持。
office.net已經漸漸淡去，此刻的微軟也明白一相情願設計一個完全以web service為中心的office版本至少在今天是不可行的。2003年10月27號的時候發布最新版本的office 2003中，啟用了一個比較保守的命名——office system 2003。從此office不再是一個純粹的客戶端軟件，而是一個完整的企業信息應用平台，不過相對於神話般的Office.net，還有很長的路需要走，不過我們可以肯定，神話僅僅是神話，這個時候的微軟已經知道.Net對於用戶意味著什麼。
在服務器系統方面，.Net enterprise server有點盛名難負，更加直接的來說是一個虛構的名字。為了更加貼近實際情況，微軟將新版服務器系統命名為Windows server system，旨在建立一個深度集成的服務器基礎結構，而從使it專業人員能夠將精力集中到滿足業務需求方面。
這一切表明，微軟在.net的推廣策略上已經趨於務實。事實上，一項新技術，必須有現實的產品支撐。微軟一向的做法，是將新技術與自己的強勢產品結合，從而讓最終用戶的需求推動開發者轉向微軟技術。然而，在.net推廣之初，這一策略並沒有很好的貫徹。只是經過了這個務實階段之後，微軟才重新回到了自己的正確路線上。將.net技術與Windows和Office兩大拳頭產品結合，這表明.Net已經邁上穩健發展之路。
office.net已經漸漸淡去，此刻的微軟也明白一相情願設計一個完全以web service為中心的office版本至少在今天是不可行的。2003年10月27號的時候發布最新版本的office 2003中，啟用了一個比較保守的命名——office system 2003。從此office不再是一個純粹的客戶端軟件，而是一個完整的企業信息應用平台，不過相對於神話般的Office.net，還有很長的路需要走，不過我們可以肯定，神話僅僅是神話，這個時候的微軟已經知道.Net對於用戶意味著什麼。
在服務器系統方面，.Net enterprise server有點盛名難負，更加直接的來說是一個虛構的名字。為了更加貼近實際情況，微軟將新版服務器系統命名為Windows server system，旨在建立一個深度集成的服務器基礎結構，而從使it專業人員能夠將精力集中到滿足業務需求方面。
這一切表明，微軟在.net的推廣策略上已經趨於務實。事實上，一項新技術，必須有現實的產品支撐。微軟一向的做法，是將新技術與自己的強勢產品結合，從而讓最終用戶的需求推動開發者轉向微軟技術。然而，在.net推廣之初，這一策略並沒有很好的貫徹。只是經過了這個務實階段之後，微軟才重新回到了自己的正確路線上。將.net技術與Windows和Office兩大拳頭產品結合，這表明.Net已經邁上穩健發展之路。
未來展望
longhorn需要到2006年才能夠發布，我們完全可以認為，這個就是四年以前微軟提出的.net戰略時希望達成的夢想之一，集成互聯，同時擁有一個非常出色的用戶體驗。微軟當初承諾在三年內實現這些基礎架構的建設，現在看來這個時間恰好需要多一倍，也就是整整六年的時間。這個號稱完全重新構建的操作系統才能夠稱得上.net操作系統，關於其中的avalon(圖形渲染技術)、indigo（通信子系統）、winfs（文件存儲系統）還有純粹的.Net編程接口winfx。
相信2006年的longhorn發布的時候，.net應該已經得到業界的認同，並且已經出現了相當部分基於.net的成功案例，對於.net的fud(fear/uncertainty/doubt，恐懼/不確定性/疑慮)也已經煙消雲散，.Net和J2EE真正意義的站在同一個水平線上去對話。
而在longhorn中的indigo子系統，則以一種更加透明的方式來實現系統的部署，於是“一次編寫，多次部署”也成為可能。隨著.Net提出微軟一直倡導的smart clIEnt技術也得到完美的體現，這個時候已經可以不去考慮桌面和浏覽器的區別，如果說有，那麼只是一種部署方式的差異，而解決這個問題的核心在於xaml及其和win32 api等同的winfx技術。
“一切皆是web service”，那個時候的確可以做到當初.Net戰略希望的所有子系統都通過web service通信（當然了，那個時候的web service不再是今天的效率）。期待總是期待，畢竟還有兩年的時間去觀望，也許到了日後一切全部變了樣。
但是我們相信，未來的.net會成功，就如同微軟一貫以來的成功，於是今天我們不是考慮是否使用.net而是考慮何時選擇.Net，當然，每一次的選擇和放棄都是一種痛苦。
.Net重要技術思考
.Net remoting
從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恰恰是這個戰略的犧牲品，雖然擁有與生俱來的優點，不過依然生不逢時。
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（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年。
.Net改變了什麼？
microsoft，是否依舊“micro”？
原先的microsoft已經不再“micro”，20多年的高速成長，這家從pc起家的軟件公司已經早早稱霸全球，除了在pc機方面保持絕對的壟斷優勢以外，在服務器市場，也已經發起對於高端應用的沖擊，Windows 2000就是這個戰役的經典之作，按照一貫的策略，微軟依賴其價格優勢和最簡單的操作界面一點一點地換取中小企業的“芳心”，而對於大企業應用，雖然還無法改變其“小丑”形象，但是顯而易見，那樣的關系越來越“暧昧”。
評論界很多人都認為微軟是一個以銷售起家的公司，畢竟微軟的技術從來不是最好，卻能夠笑到最後，我們無法否認過去很長一段時間微軟是依靠Windows和Office的銷售來支撐整個公司的高速運轉，但.Net戰略的推出則展現出微軟從銷售型轉向服務型企業。畢竟隨著技術的發展，在操作系統和辦公軟件上面的利潤已經越來越透明，加上Linux的沖擊和微軟自身舊產品如Windows 98，Office 97等等已經足夠“好用”，這樣帶來的結果必然是企業it采購成本的大幅度縮減，微軟自身也必須找尋更好的商業模式來獲取穩定的收入。
將“Windows時代”帶入“.net時代”，對於微軟公司而言，需要做的有很多很多，包括自身定位，包括如何打破用戶的顧慮和恐懼，當然還有一直以來不是很友好的公關形象。於是.Net戰略成了微軟一個新的戰場。
改變了開發人員
很多人在會抱怨新的技術更新太快了，如果跟著微軟走總是需要不斷地學習新技術，而相對來說其他的技術更新就沒有如此之外，至少能夠保持一段時期的穩定，這點就從c++那麼多年以來的發展還有Java就可以看得出來。
不過，世界總是在變化，有很多東西總是在不斷改變，與其拒絕變化然後徘徊不前，不如去擁抱變化，當然這裡提到的並不是盲動的跟隨改變，然後成為“語言學習機器”。
4年的發展，.Net已經漸漸的成長為可以和J2EE對抗的應用平台，並且在中低端的應用開發中，能夠顯著的提高生產力，這是何樂而不為。不過微軟在.net的營銷並不是非常成功而干脆，至少在web service方面對於廣大的開發人員是一種誤導，這個世界沒有絕對的“銀彈”，Java不是，.Net也不會是，而XML web service在微軟自身的定位的反復不定也讓人有點疲憊。
帶來一個新的選擇，帶來更高的生產力，帶來一種新的理念， 作為一線的開發人員，我們曾經為選擇一個工具或者平台困惑、迷惘、狂熱、追逐，最後堅定或者放棄。
這個世界本來就是一個需要不斷探索的世界，.net同樣如此。從總體上來說.Net，經歷從狂熱到迷惘，在到務實，從而逐步走向成熟的過程。
