記住，這是1.0版本，這不是Visual Studio 7.0；這不是COM++++；這不是Visual Basic 7.0。十分確切的說，這是全新的。它和大量的新代碼壹起引進。妳要特別仔細考慮如何計劃.net的采用。特別是在以後的24個月裏。<P title="" P XMLns:fo="有什麽建議？
這是壹個什麽時候將他們拖、拉、或者尖叫著穿過.net的懸崖的問題，而不是是否需要穿過.net懸崖的問題，不管他們是否願意。然而，我不希望看見許多人試圖壹次重寫他們的所有的Visual Basic代碼或者Visual C++代碼。我們應該逐步的開展。.net將很快被引用到新的開發中。在Visual Studio .net出現的頭壹兩年，妳將會看到壹個混合模型，新開發的代碼中30％的將是ASP.net代碼（我預見ASP.net的擴展將會非常非常之快），但是70％將仍然是COM，COM+代碼。商業應用
Javascript:openWindowRes('DotNetMagazine/2001_12/WhereItIs/BusinessCase.htm');">計劃向新技術轉移
由於.net的許多優勢和微軟的強大的市場努力，.net技術在應用程序開發中最終將被廣泛采用幾乎是可以肯定的，特別是對於中小型企業....
</TABLE>我對嚴謹的客戶的壹般建議是，不要把有緊急任務的應用程序在很大程度上依賴於.net，至少在.net發布後六到九個月不要這樣做，即2002年8月之前。<P title="" P XMLns:fo="做壹些小的原型，壹些沒有緊急任務要求的程序。這取決於beta代碼，第壹個產品版本，或者第壹個服務包能為妳帶來些什麽。盡管如此，我們推薦妳采取保守的方法。假設壹個糟糕的情況：妳的30%-40%代碼將遷移，妳將不得不重寫或者重設計剩下的代碼。別指望微軟會提供自動工具來遷移妳的代碼。<>對早期的采用者也有壹些好的原因。首先是顯示公司在Web Services策略方面的競爭力，妳正在尋找在接下來的12個月裏支持Web Services最好的平臺。<P title="" P XMLns:fo="是另壹個原因。太多的程序員從事ASP的開發，如果妳正在ASP執行或者安全方面苦苦掙紮，或者受夠了整個ASP的生存空間。ASP.net是壹個更強大的環境。實際上，微軟已經有了大量的早期采用者，他們已經在ASP.net系統的測試版下開發。<><P title="" P XMLns:fo="有壹些重要的新特征正好可以幫妳實現，在許多情況下，冒險早期遷往.net是因為它在移動和無線設備方面做得更好。<>如果妳不關心Web Services，這裏沒有壹個無可抵抗的和強制性的原因，讓妳去很快地采用它。實際上，這就是我們說為什麽大多數公司將采用壹個相當漸進的曲線來采用它。有許多因素要考慮。要看多少人采用這種主流技術。要參考專家的建議。要看第三方的支持、前景市場的支持。要看本地的.net服務的組件提供者。要看所有的測試公司。要看源代碼管理公司的提供。Visual Studio .net發布的第壹年，早期的采用者將會把他們的代碼按70/30的比例劃分在舊平臺和新平臺上。在大約壹年半後，我們期待比率會變成30/70。妳將看到70％的本地.net代碼將出現在基於微軟的解決方案中。傳統的公司將在Visual Studio .net發布後的24到36個月開始遷移。大約2005年，我們將期待95％的本地.net開發。讓我們來討論.net語言和在遷移應用程序到.net的過程中起作用的部分，從Visual Basic .net開始。
這是壹個好消息，Visual Basic 變成了壹種成熟的語言。它開始面向對象設計，使用類框架和.net中的其它零碎，VB.net已經變成了壹個更強大的工具集。事實上，還沒有哪些商業應用程序不能用VB來實現。<P title="" P XMLns:fo="有了許多新的語法和設計問題。這意味著對Visual>我認為在接下來的48個月中，60％或者更多的C++開發者將轉向C#.C++將仍然會使用。它將會使用在COM和COM+領域，甚至在.net中它將仍然會被使用，但是它將仍是系統層的編程語言。C#的快速開發應用程序的能力和C#和.net組件模型集成工作的能力將會起到壹個大的作用。這是我從用戶那兒聽到的最多的問題。我可能今年與八九百人討論過，幾乎壹半的問題都是直接地或間接地關於.net與Java相比較的問題。我告訴他們我認為Microsoft和Java將支配電子商務應用程序開發，也就是說，大多數新的項目將會基於這兩個平臺之壹。他們到2005年將占有80%的市場。誰也不會。大多數大公司將會兩者都使用。現在，Java基於它的跨平臺的能力，在大公司中還有很強的實力。小公司不能負擔得起使用兩者，他們將會轉向其中之壹。微軟因為它的成本低和眾多的開發者，對中小型組織還是很有吸引力的。為了完成.net難題還需要做什麽？
中間件架構應該被拿走。我們需要MTS的替代品。我們需要壹個與本地.net同步的messaging broker。更有效的是，我們需要作為本地.net服務的COM+的替代品。當然。妳已經有了數據庫APIs和類似的功能。但是我們需要的是Java 2平臺、J2EE在.net上的替代品。現在，如果妳仔細看那些零碎功能的話，我們已經有了壹半了。有壹個清晰的Java 2平臺、標準編輯器(J2SE)的替代品，不久我們就會有Java 2平臺、J2ME的替代品—J2ME與.net Framework緊密相關。但是，微軟還沒有建立壹個真正的J2EE的替代品。我們需要看到.net技術註入SQL Server，這在SQL server的下壹個主流產品Yukon中將會看到。我們需要看到各種.net技術，像BizTalk，具有諷刺意味的是，它現在還什麽都不能做。微軟的門戶網站，電子商務軟件，所有的零碎東西都需要在.net上執行。他們需要整合將被淘汰的技術。妳提到了Web Services的重要性，那我們將會先看到哪種類型的Web Services呢？
我前面提到大多數公司將會同時使用Java和微軟的技術。Web Services是壹個很好的方法來整合它們並使他們可以交互操作。我們認為Web Services在移動基於所有權信息方面起著相當重要的作用。<P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" Services的問題，就象其它問題壹樣，還很不成熟。實際上，現在整個XML消息的概念還極不成熟。我們現在只有所有的5%或者10％，我們最終需要全部的XML基礎。< >Web><P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" Services將是壹個文化問題。企業將不得不適應系統開放的思想和實時工作的思想。好消息就是有了許多用B2B的基礎。壹些特別縱向聯合的企業已經大規模地采用這種方式。< >我認為抑制在公***的互聯網上使用Web>我認為在使用這項技術時仍然缺少技巧。許多開發者將把Web Services當作分布式對象模型壹樣執行。他們將說“好的，Web Services僅僅是包裝了DCOM或者COM組件和Enterprise Java Beans組件，”，這是不對的。Web Services是松耦合的、異步消息協議，而不是鎖定的、同步機制。人們第壹次將不可避免的犯錯誤。<P title="" P XMLns:fo="http://www.w3.org/1999/XSL/Format" Services將不會變成主流。< Services會有很好的前途，它會是無處不在的相當廉價的服務通訊機制。不管這些服務是在壹個子系統，壹個企業、跨越壹個行業內，或者甚至跨越不同的行業。妳可以減少進入這個商業領域的障礙。但是這些好處將不得不和組織結構帶來的新問題相比較。這樣，我們認為2003年之前的這段時間，Web >妳可以相信Web>這是現在Web Services的壹個大黑洞。我們還沒有看到任何好的定價模式。我認為我們將會看到，在某種程度上，小的付款模式將會壹點點出來。但是還沒有回答大的付款模式的例子。妳知道，我把HailStorm看作是壹個大的、具體化的Web Services的例子。然而現在我聽到大量的反對聲，因為它是微軟的。人們認為這是微軟控制互聯網的“Phase II”。我相信如果它不是從微軟而是其他的公司，HailStorm將會直接受到大家的歡迎。讓我驚訝的是，如果AOL或者和它的合作夥伴不提出和HailStorm長期競爭力的產品。我相信它會成功。我認為人們非常關註的電子商務將會有同樣縱向聯系的市場。已經轉向電子商務的行業將會是第壹個使用Web Services的行業。它是下壹個邏輯革命。</A>