這篇文章很多地方借鑒了David Chappell的《Understanding .NET》和其他的一些網上的文章，但是也有一些我自己的文字。寫這篇文章的本意是希望能用一些較少的文字能給讀者對.NET一個全面的、但是并不深入的印象。這裡謹對《Understanding.NET》的作者David Chappell及譯者侯捷、榮耀還有其他的作者們表示感謝！
.NET概觀
微軟.NET的出現，可以說是一場地震。它将震撼Windows環境下工作的任何人，同時也将在範圍更廣的世界裡産生餘震。微軟一次性的帶給我們那麼大的變化，要我們适應它，短期來看，将使我們的日子更加難過，畢竟要學的東西太多！然而一段我們掌握了這套新工具和新技術，大多數Windows開發人員将會發現，他們有能力在更短的時間内建構數更具威力、更有用的軟體。
一． 什麼是.NET
.NET是一個施用于一系列技術上的商标微軟将.NET視為數字化未來的一個遠景和平台。如果更具體更準确地看待這種創新，則是把.NET視為一個商标，一個微軟已經施行于數種不同技術上的商标。這些技術有些是全新的，提供新的服務和新的可能性，另一些則允許我們以最新的方式來建立我們今天已經知道的各類Windows應用程式。當然，也有一些.NET家族成員隻不過是裝飾着.NET牌子的現有技術的新版本而已。
.NET是軟體成為一種服務的轉移.NET在這個方面的意義是最被廣泛接受和了解的。“軟體就是服務”的曆年最初是在
1997年左右由Oracle的CEO Larry Ellison以及SUN的CEO Scott McNealy在網絡計算機的概念大行其道的時候提出的。不過Oracle和SUN并沒有真正将這個概念變為現實，他們的視角更多的集中于資源集中化方面。不過，當初聽到Ellison和McNealy這番見解的公司——當然包括Microsoft，也認識到了這種見解說出了軟體産業面臨的一個巨大改變，.NET則是Microsoft對這種概念，這種變化作出的自己的反應。
.NET是一個新的程式設計模型——也就是說是Internet平台Micorsoft正在趨向于将.NET看作一個系統。在表面下，它包含了兩種不同的程式設計模型：一個是Web服務程式設計模型，另一個是系統程式設計模型。
Microsoft開始把.NET系統程式設計模型作為.NET整體的一個組成部分。計劃最終以此代替現有的元件對象模型(Component Object Model，COM)以及Windows應用程式程式設計接口(APIs)，這個現在還沒有最終正式定名的模型使用一系列新的基礎類。
.NET之中最重要的新技術首推Web Services。如其名稱所示，Web Services提供了某些功能，讓我們得以通過網絡加以調用。大多數頂着.NET商标的技術都可以在某種程度上直接支援Web Services。然而.NET絕非僅僅是Web Services而已，微軟置于.NET商标傘下的技術包括：
.NET Framework：包括通用語言運作層（Common Language Runtime,CLR）和.NET架構類庫。CLR是建造一系列新應用程式的标準基礎，.NET類庫則為許多基于CLR的應用程式提供一個新的标準開發環境。這個類庫，包含的技術有：ASP.NET，最新一代的ASP（Active Server Pages）技術；ADO.NET，最新一代的ADO（ActiveX Data Objects）技術；以及對“建構和使用Web Services”的支援等等。微軟還發行了一個.NET Framework精簡版，名為.NET Compact Framework，用于小型裝置如個人數字助理（personal digital assistants，PDAs）上。
Visual Studio.NET：支援多種可使用.NET Framework的程式設計語言，包括Visual Basic；一個增強版的C++；一個基于.NET的Java替代語言J#，以及一個為.NET Framework量身打造的全新語言C#。
.NET My Services：一組服務，允許使用者存儲和通路位于網際網路可達之伺服器上的個人資訊，例如日程表和位址簿等等。這些服務還提供諸如認證（Autherntication）這樣的通用功能，使客戶能夠證明自己的身份；也提供了一個“向不同裝置上的客戶發送消息”的方式。
.NET Enterprise servers：這是一系列軟體伺服器，包括、Exchange Server 2003、SharePoint Server 2003、Project Server 2003、BizTalk Server2000，Application Center 2000、Commerce Server 2000、Host Integration Server 2000、SQL Server 2000等等。除了幾個叫2003的産品外，其他的很大程度上與這裡說的.NET技術沒有什麼關聯，但是顯而易見，在未來的版本當中，他們将全部基于.NET技術建構，上面幾個叫2003的版本已經證明了這一點。
二． .NET的特點
1. 高效率開發
通過.NET Framework為我們提供的一個龐大而有結構清晰的類型，使得我們的程式設計變得異常輕松，還有自動垃圾回收機制等等一系列新的特性，可以讓我們的程式員騰出更多的精力放在考慮如何實作客戶所需要的業務邏輯上，而不是計算機的控制上為記憶體如何分派之類的事情頭痛。甚至無論你是開發哪一種應用程式，無論是C/S、B/S、還是智能裝置亦或是資料庫程式設計，都可以使用你最熟悉的一種程式設計語言而不需要去學習諸如C++、ASP、SQL等等各不相同的多用語言。.NET還帶來了多種語言之間的無縫內建，例如一個系統同時可以采用多用程式設計語言來開發，VB.net編寫的類可以友善的再用C#繼承。這些都大幅了提高我們的開發效率。
2. 多平台特性
盡管不可否認，到目前為止.NET應用程式還隻能運作于Windows平台上，但.NET天生就為跨平台應用做好了準備，據我們所知，微軟自己還有第三方開發商已經在為.NET程式運作在Unix、OS2、Linux等等系統上工作着（如開源項目Mono）。我們還可以看到我們的.NET應用程式将可以運作在PDA甚至手機上。不久的将來，我們将可以隻關心我們的應用程式将如何滿足客戶的需求而不用考慮基于何種平台來開發。
3. 無接觸部署
借助于.NET的反射特性，.NET應用程式都可以精确的描述自身。這就使得無接觸部署成為可能，.NET應用程式無需在系統資料庫中儲存資訊，隻需簡單的XCOPY便可正确的在使用者的機器上運作，這使得企業的部署成本将會大為降低。
4. 消除Dll Hell
同樣是基于.NET的反射特性，每一個應用程式将可以清楚地知道自己需要使用哪一個Dll，同一個Dll的不同版本可以彼此和平共處，進而徹底消除讓我們頭痛的Dll Hell。
5. 可信賴計算
長期以來，微軟系統的安全性問題一直備受诟病。但終于，比爾蓋茨決定改變這種現狀。在.NET中，這種安全性的考慮直接放到了代碼級。通過一系列的技術，如代碼通路安全(Code Access Security)、基于角色的安全、強名稱（Strong Name）、權限和權限集等等，最大限度地保證了系統的安全性。
三． .NET Framework體系結構
.NET是分層的、子產品化的，一及層次結構化的。.NET Framewok的每一層都是一個抽象層。其中，.NET語言是頂層，也是最為抽象的一層。而公共語言運作庫則位于底層，它是最不抽象、最靠近本地環境的一層。這一點很重要，因為公共語言運作庫需要與操作環境緊密合作來管理.NET應用程式。.NET Framework被分成了多個子產品，每個子產品都有它們各自特定的責任。最後由于高層隻從底層請求服務，是以.NET又是層次結構化的。
四． WebServices(Web服務)
要想透徹了解.NET，就必須透徹了解Web Services，還必須領會剛剛列舉出來的每一種.NET技術的基本要素。
今天，Web應用程式的典型通路方式為GUI近十年來，軟體世界沒有什麼比Interne和WWW帶來的沖擊更大。區區20年以前，還是大型機的時代。那時隻有極少數人能夠使用計算機，而且隻能通過鄰近的資訊産業機構。個人電腦和圖象化使用者界面的出現卻改變了一切，将計算機普及到了千家萬戶，并使它真正成為一種可以大工業生産的商品。企業界意識到，由個人電腦聯結的網絡和基于個人電腦的伺服器可能改變他們的商務模式，而個人電腦對消費者來說也迅速地成為新興的娛樂媒介。然後，網際網路接踵而至。它革命性地改變了我們的交流方式，創造了豐富而新穎的資訊和娛樂資源，并且在“商務”的前面加上了一個代表“電子”的字母“e”。今天，全球有将近三億人口正在使用網際網路。國際資料集團提供的資料顯示，今年全球的網上交易金額将超過250億美元。World Wide Web已經從根本上改變了我們通路資訊、購物、找工作以及日常生活的方式。他通過具有圖形界面（GUI）的應用程式很人們直接互動而做到這一切。毫不誇張地說，以GUI為主的應用程式，造就了Web的今天。
然而，GUI不是Web的全部，Web Services代表了Web的未來以GUI為主的應用程式可能就不再是下一階段Web的交通工具了。面對這些網絡神話，我們仍然發現存在着巨大的改進空間。今天的網際網路在很大程度上還在模仿舊式大型計算機的工作方式。盡管有充足的帶寬資源，大量的資訊還是被“鎖”在了中央資料庫裡，并由“保安人員”看守。使用者必須依靠網絡伺服器來完成所有的上網操作，這酷似老式的分時複用系統。網站好象一個個孤立的小島，并不能按照使用者的指令在它們之間進行有意義的交流。今天的網絡似乎隻能通過單個的網站向單個使用者提供有限的服務 -- 因為大多數的網頁隻能呈現HTML格式的資料“圖檔”，而非資訊本身。（對大多數網頁來說，在現有技術條件下要兩者兼顧是非常困難的。）非但如此，浏覽器本身在很多方面都隻是一個被美化了的“啞巴隻讀終端”-- 你可以輕易地浏覽資訊，但是很難進行編輯、分析和複制（實際上也就是知識工作者需要做的所有工作）。“個性化”隻意味着重複地進入網站，并不斷地将個人隐私洩露給你所通路的每一個網站。你必須适應科技，而不是科技反過來适應你的要求。我們希望我們能通過多種方式來擷取資訊，而不僅僅是浏覽器。如果提供這些Web服務的應用程式可以由外界通過程式設計來通路，那麼外界就可以更容易且更有效率的使用這套重要的服務。用微軟的話說，“一切都是服務”。這些網絡服務的客戶可以不再是坐在浏覽器前面的人，而是運作在桌上電腦、行動電話或其他裝置上的軟體。客戶軟體可以通過多種方式來調用那些應用程式的遠端操作，并使用XML（Extensible Markup Language）傳輸資訊。換句話說，這用應用程式可以用“Web Services方式”加以通路。
Web Services可被應用于很多方面這種技術可應用于很多方面。它可用來讓桌面客戶或手持裝置客戶通路Internet上的應用程式，利于預定系統；也可以用于B2B整合，通過Internet連接配接不同企業組織的應用程式。Web Services甚至還可能用于企業應用整合，進而将企業組織“原本運作于專用網絡上”的應用程式連接配接起來。所有這些案例中，Web Services技術都為型型色色的軟體小子產品提供了“标準膠水”。
XML Web services是完全公開的，可以通過任何平台實作。.NET My Services 是XML Web services的一個具體實作，通過XML Web Services的方式來傳輸資料，具體地說，就是通過以XML描述的SOAP消息來實作資訊的交流，而SOAP消息可以通過HTTP或者DIME(Direct Internet Message Encapsulation，直接Internet消息封裝)協定來傳遞。XML Web Services的工作原理如圖所示。結合Microsoft .NET Passport使用者身份認證系統，.NET My Services能夠以使用者為中心将應用程式和服務高效內建，并實作個體群組織的協作與資訊共享。
Web Services技術可以分解為四個獨立領域，每一個領域都解決了問題的某個特定方面。
描述“經由網絡發送的資訊”：調用一個遠端操作時，往往必須傳入一些參數，并取回某些資訊。如果使用Web Services，這些資訊必須以XML描述。作為一種被普遍接受用以描述資料的現代通用語言，XML可以描述和交換不同種類的資訊。
定義“Web Services能力”：必須存在某種機制，使Web Services供應者能夠精确定義他所提供的Services的技術細節，并且能夠被服務的接受者所了解。這由Web Services描述語言（WSDL）完成。而WSDL自身也是采用XML來定義的。
通路Web Services：一旦定義好接口，客戶必須使用某種協定調用該接口内的操作。這裡并不存在什麼專用協定，然而最重要的選擇是SOAP（Simple Object Access Protocol）。SOAP提供一個辦法，可以辨別出“将調用那一個操作”：他以“采用XML定義完成的資料”傳輸操作的輸入，并同樣以“采用XML定義完成的資料”回傳任意結果。
找出Web Services：對運用Web Services開發用戶端程式的人員來說，必須存在某種方式，讓他們知道可以獲得什麼樣的服務，讓他們知道Web Service提供了些什麼？其接口看起來是什麼模樣？考慮到Internet的存在，建立一個标準的Registy用以存儲和通路資訊是很合理的。這正是UDDI（Universal Description，Discovery，and Integration）技術所作的事情。使用UDDI，Web Services供應者便可以用标準方式對他們所提供的東西廣而告之，使客戶得以獲悉各家供應商提供了些什麼服務，并讓客戶知道，為了開發用戶端軟體，他們需要了解些什麼。
Web Services是通用的：Any Time，Any Where以上每一種技術都是由成群的廠商和使用者彼此協作而開發出來的。比如XML是World Wide Web協會（W3C）資助的一個大型團體開發出來的，WSDL主要由Microsoft和IBM開發出來，SOAP原先由Microsoft、IBM、UserLand Software、DevelopMentor，其他一些團體也扮演了一定的角色。UDDI原先由Microsoft、IBM和Ariba開發，後來又有更多組織加入，共同努力。沒有任何一個Seb Services技術源自單一廠商提供的解決方案。是以，奠基于XML、WSDL、SOAP和UDDI之上的Web Services實質上可用于所有平台、所有語言和所有對象模型。再加上Web Services的無與倫比的穿越防火牆的能力，無論何時、無論何地、也無論你的系統是架構于Windows、Unix、Mac或者Linux甚至PPC、Palm之上，隻要有Internet，您就能享受Web Services提供給您的服務。
應用Web ServicesWeb services幾乎可以用在任何場合。最顯而易見的用途分為三類：
允許經由Internet，以可程式設計方式通路應用程式：這樣你就可以不必受限于浏覽器了，你可以使用選擇更有效率的方式來完成，通過一個适合用戶端裝置的界面，你可以表達你的意願，并貫徹你的意願。Microsoft .NET意味着簡單化的整體服務；統一的資訊浏覽、編輯和授權；檢視你的資料、工作和線上與離線媒體；一種整體的系統方案；随時随地的個性化；絕對的自由。例如，對于你個人資訊的任何修改 -- 無論是通過個人電腦、便攜裝置還是靈通卡 -- 将即時和自動地通知到所有需要這些資訊的地方。例如你可以随時随地通過你喜歡的方式來在網上預訂機票，而不僅僅是通路航空公司的網站。
以這種方式通路Web Services，還引發另一種可能性：為何不讓某些Service為其供應者（公司）創造營收呢？正如奠基于浏覽器之上的Web應用程式支撐新式商業模型，進而帶來Internet大爆炸一樣，Web Services也能為他們的供應者帶來新的賺錢方式。雖然你的牙醫不可能因為你做了一個預約就向你收費，但有些服務确實肯定要收費的。
B2B整合：Web Services的另一個重要應用是B2B整合，一般來說它也依賴于Internet，将運作于不同企業組織中的軟體連接配接起來。就目前來說，各個企業的軟體在Internet的海洋裡還像是一個一個的資訊孤島，要連接配接起來還需要專門而特别的方法。其原因是多方面的，平台不同、軟體不同、防火牆……等等這一些限制了彼此之間的連接配接，Html雖然是通用而标準的，可是那隻适合人看，想要交程式去了解網頁中包含的資訊，那是難上加難。而Web Services則提供了一個通用而标準的方式，使得這不再隻是個美好的夢。可以想象，Web Services在企業協作比如供應鍊管理等等方面将發揮出它神奇的作用。
A2A整合：許多企業組織最困難的問題就是如何将現有應用程式連接配接在一起。不論規模如何，每家公司都有一些以不同語言在不同時間編寫出來的軟體，混合運作于不同系統上。将這些繁雜的應用程式聯合為一個有用整體，已經是這些公司面臨的巨大挑戰之一，更别說為這個混合怪獸加上新程式了。而Web Services則為這個惱人的A2A整合問題提供了一個有效的解決方案，直截了當的說，Web Services為這個五花八門的環境提供了一盒不錯的萬能膠。
Web Services的未來一片光明Web Services無疑是個好點子。他讓許多廠商開放的Services得以運作于跨越intranet和Internet的所有平台上，并是以帶來一種新的開放世界的方式。Web Services底層蘊含的技術——XML、WSDL、SOAP、UDDI——都是相對較新的技術。盡管這些技術的資曆并不深，但它們都被多家廠商支援，并且看起來都有可能在将來的分布式計算環境中發揮重要作用。奠基于浏覽器之上的應用程式，造就了Web璀璨的今天，而Web Services則可能成就出更美好的明天。并由此，将給我們帶來一個全新的理念：
一切都是服務。
五． Common Language Runtime(通用語言運作層)
.NET Framework中的任何東西都依賴CLR通用語言運作層（CLR，Common Language Runtime）是.NET Framework之中任何東西的基礎。要想透徹了解.NET語言如C#和Visual Basic.NET，你必須了解CLR；要想透徹了解.NET Framework類庫如ASP.NET和ADO.NET以及其他東西，你也必須了解CLR。由于.NET Framework已經成為微軟新軟體的預設基礎，是以任何打算在微軟環境下工作的人，都應該努力把握CLR。
CLR定義了哪些東西一般而言每一門語言都有自己的一套獨特文法、一套控制結構、一道資料類型（Data Types），以及一套“Class如何繼承”的概念。語言設計這所作的決策，會受其目标應用程式（target applications）的影響，也就是說，“語言使用者可能拿這個語言來幹什麼”會影響語言當初的設計。當然，語言設計者也難免摻雜個人感情因素。
然而，對于一門現在程式設計語言應該提供些什麼成分，大多數人都會達成共識。盡管與方面的意見會不同意，但語義方面大家有普遍的一緻意見。于是，
CLR定義了一套可被多種語言使用的通用語義集CLR還提供了其他通用服務：
Garbage Collection（垃圾回收），自動釋放不再被引用的受控對象
Metadata（中繼資料）标準格式。每一個類型的資訊都存儲在該類型編譯後的代碼裡。這和COM不同，不再有獨立的類型庫（type libraries），也不再需要IDL。如今的interfaces和classess直接使用開發人員所采用的任何程式設計語言來定義，而後再被轉換成metadata标準格式。
一個通用體制（Common scheme），用以組織編譯後的代碼（稱為裝配件，assemblies）。裝配件可以由一個或多個動态連結庫(Dynamic Link libraries，DLLs)和/或可執行檔案（Executables，EXEs）構成，并内含他所包含之classes的metadata。單一應用程式可使用來指一個或多個裝配件的代碼，是以，每一個裝配件都可以明确描述他所依賴的其他裝配件。
何謂受控代碼（Managed Code）建立于CLR之上的軟體，稱為受控代碼（managed code）,CLR提供了好幾樣東西，用來建立和運作這種特殊代碼。最基礎的東西是一套可被CLR-based語言所使用标準型别集（standard format for metadata），那是“以标準型别建造而成的軟體”的相關資訊。CLR還提供受控代碼的打包（packaging）技術和一個用以運作受控代碼的運作期環境。
開發受控代碼：通用型别系統（CTS） CTS定義了核心語義，但沒有定義文法。CTS并不規定特定文法或關鍵字，隻是定義了一套通用型别，他們可用于許多語言的文法上。每一種語言都可以自由定義他所希望的任何文法，但如果某個語言點基于CLR之上，它将至少使用CTS定義的一部分型别。
CLR-based語言以不同的方式來顯露CTS types。CTS定義的一整套types在CLR中聚核心位置。奠基于CRL之上的程式設計語言以一種語言相依方式來顯露這些types。盡管一個CLR-based語言創造者可以自由實作CTS定義之types的任何子集，或甚至加入自己的types，但大多數CLR-based語言還是廣泛的采用了CTS所定義的types。
CLS：通用語言規範（Common Language Specification）CTS定義了一套相當龐大也相當複雜的types，但并不是所有的這些types對所有語言都有意義。CLR的一個關鍵目标就是允許開發人員以某種語言撰寫代碼，并以另一種語言調用這些代碼。但是除非兩種語言都以同樣的方式支援相同的types，否則别想成功。然後如果讓每一種語言都實作出每一種CTS types，對語言涉及者來說也消受不起。
這個難題的一個折中解決方案就是CLS。CLS定義了一個龐大的CTS子集，任何語言如果想和其他CLS語言互通（互操作），就必須準從它。
CLS定義的是CTS的一個子集，是“跨語言互操作性”成為可能。
編譯受控代碼（Compiling Managed Code） 受控代碼經過編譯會生成MSIL（Microsoft Intermediate Language，微軟中間語言）和Metadata（中繼資料）。無論受控代碼一開始是由什麼語言寫的，編譯器都會将受控代碼中的所有types-class、structs、intergers、delegates機其他東西，統統裝換成MSIL和metadata。
微軟中間語言（Microsoft Intermediate Language，MSIL）MSIL和處理器原生指令集（processor’s native instruction set）很相似。不過并不存在用以運作這些指令的硬體，至少今天如此。MSIL代碼總是在運作前先被編譯為它将運作于其上的處理器的原生代碼——不論哪一種處理器都如此。
事實上MSIL是CLR的彙編語言。在上述描述中你可以發現：CLR所定義的是一個Stack-based抽象機（abstract machine），這意味着很多MSIL操作是依據這個Stack來定義的。MSIL指令集緊密地和CLR CTS進行映射。
中繼資料（Metadata）Metadata描述含于子產品中的types的相關資訊，包括：
Type的名稱
Type的可見性，可為public或assembly
這個type繼承自什麼型别（如果有的話）
這個type所實作的任何interfaces（接口）
這個type所實作的任何methods
這個type所暴露的任何properties（屬性）
這個type所暴露的任何events（事件）
此外還可以獲得更多的詳細資訊。例如每一個method的描述，包括method的參數及其型别，以及傳回值得型别。
由于麼metadata總是存在，是以工具軟體總是可以依賴他，例如Visual Studio.NET便總是使用metadata向開發人員展示，她剛剛敲進去的那些class有哪些methods可用。
Attributes（特性）Metadata還包括attributes（屬性），存儲Metadata内的值，可被讀取并可用于控制這些代碼運作行為的方方面面。.NET Framework類庫在很多方面都依賴于它，包括制定事務需求，指定那些methods應該開放為SOAP-called Web Services，以及描述安全需求等等。
組織受控代碼：裝配件（Assembly） 裝配件由一個或多個檔案組成，這些檔案構成了一個邏輯單元。每一個裝配件都有一份清單，即裝配件的Metadata：Manifest。清單包含于裝配件的某個檔案中，并且包含了裝配件的資訊，以及“組成裝配件的檔案”的資訊。一個裝配件可以是由一個或者多個檔案組成(dlls, exes, html等等), 代表一組資源, 以及類型的定義和實作的集合. 一個配件也可以包含對其它配件的引用. 所有這些資源、類型和引用都在一manifest中描述。這個manifest也是配件的一部分，是以配件是一個自我描述的，不需要其它附加的部件對其描述! 配件的另一個重要特性是，它是.Net環境下類型辨別的一部分，也可以說是基本機關。因為，區分一個類型的辨別就是包含這個類型的配件名字加上類型名本身。舉個例子，配件A定義了類型T, 配件B也定義了同名類型T，但是.Net把這兩個類型認為是不同的類型。配件也是.Net架構用于安全政策的基本機關，許多安全政策都是基于配件的。
裝配件可以消除所謂的Dll Hell。所有的裝配件都有一個簡單的文本名稱，但是也可以由一個“強名稱（Strong Name）”,強名稱将是獨一無二的，CLR利用強名稱對裝配件進行版本檢查，施加強制的版本管理，進而有效地消除所謂的Dll Hell。如果想将裝配件安裝到GAC（Globle Assembly Cache，全局裝配件緩存）中，就一定要有一個強名稱。
即時編譯（Just-in-time compilation，JIT）開發人員編寫的受控代碼在被編譯成MSIL之後，在運作時會被再編譯為原生代碼。有兩種方式可以完成這個目标，一種是在運作期逐一編譯Methods的MSIL代碼，另一種是在裝配件被運作前整批的全部編譯為原生代碼。
将MSIL編譯為原生代碼的一個最常見的辦法，就是先讓CLR裝在裝配件，然後在每個Method第一次被調用時編譯之。由于每個Method都隻在第一次被調用時才被編譯，是以我們稱之為即時編譯（JIT）。每一個Methods在第一次調用被編譯之後便會被緩存起來，這樣後面再次調用的時候便無須再編譯。
當一個Method被編譯時，同時也被檢查型别安全，這個過程被稱為驗證（verification），檢查範圍包括method的MSIL和metadata，以確定代碼沒有做非法通路。待會将要講到的“
CLR内建安全功能”即依賴這個驗證過程，它也被用于檢驗受控代碼行為的其他方面。
代碼通路安全（Code Access Security）代碼安全問題一直是一個令人頭痛的問題，你不知道你安裝的軟體在你的電腦上做了些什麼。尤其在Internet無處不在的今天，更是可能給你帶來巨大的安全危機。必須要有一種辦法來限制代碼——尤其是下載下傳而來的代碼——的活動範圍。
“代碼通路安全”機制可限制運作中的代碼的行動範圍。目前，控制“下載下傳代碼是否可運作”的Windows典型解決方案是：問使用者，但是.NET代碼安全機制并不依賴使用者的知識。CLR-based代碼究竟能做些什麼，有賴兩種東西的交集：代碼要求的“權限”是什麼？代碼運作時安全政策實際上授予的“權限”又是什麼？為了标明它需要哪一種通路權限，裝配件可以精确的指明需要運作環境給它什麼樣的權限。代碼通路安全性使得CLR可以根據裝配件名稱、釋出商、從何而來等線索，限制特定裝配件的行為能力。這種機制非常具有彈性，提供很多選項，可以滿足廣泛的要求。而且，在一個彌漫全球網絡和移動代碼的世界裡，題共一種強制手段來限制代碼的行為能力和範圍，實在是不可或缺。
角色安全性（Role-Based Security）CLR提供的角色安全性解決了代碼通路安全性所不能解決的另一個問題，那就是如何去限制某些使用者可以運作某些代碼，而另一些使用者則不能運作這些代碼。CLR允許為每一個method添加屬性來指明允許運作這段代碼的有哪些角色，之有使用者所扮演的角色與之相比對時，這段代碼在被允許運作。
垃圾回收（Garbage Collection） “垃圾回收”機制自動釋放不再被使用的對像。對于每一個C++程式員來說，可能最頭痛的就是記憶體洩露問題了，可能C++程式員認為，記憶體太重要了，是以不能由系統來自動管理。但在計算處理能力高速發展的今天，.NET程式員認為，如何處理業務邏輯，建立随需應變的系統才是最重要的，既然如此，又何必不把記憶體交給系統來管理，自己好騰出精力來實作業務邏輯呢？
在.NET Framework應用程式執行過程中，managed heap起到了至關重要的作用。每一個reference type（例如每一個classes和每一個string）的實體都沒配置設定于heap之上。一旦應用程式運作起來，heap記憶體會被塞滿。為了建立新的實體，程式必須獲得更多可用空間。這件事的處理過程稱為“垃圾收集”。
垃圾回收器跟蹤并回收托管記憶體中配置設定的對象，定期執行垃圾回收以回收配置設定給沒有有效引用的對象的記憶體。當使用可用記憶體不能滿足記憶體請求時，GC會自動進行。
在進行垃圾回收時，垃圾回收器回首先搜尋記憶體中的托管對象，然後從托管代碼中搜尋被引用的對象并标記為有效，接着釋放沒有被标記為有效的對象并收回記憶體，最後整理記憶體将有效對象挪動到一起。這就是GC的四個步驟。
由上可見，GC是很影響性能的，是以一般說來這種事情況還是盡量少發生為好。
為了減少一些性能影響，
.net的GC支援對象老化，或者說分代的概念，代是對象在記憶體中相對存現時期的度量機關，對象的代數或存現時期說明對象所屬的代。目前.net的垃圾回收器支援三代。每進行一次GC,沒有被回收的對象就自動提升一代。較近建立的對象屬于較新的代，比在應用程式生命周期中較早建立的對象的代數低。最近代中的對象位于零代中。每一次GC的時候，都首先回收零代中的對象，隻有在較低代數的對象回收完成後仍不能滿足需求的情況下才回收較高代數的對象。
應用程式域（Application Domains）應用程式域又是一個新的概念。我們知道，程序可以将“它所包含的應用程式”和“其他所有應用程式”隔離開來，進而使一個應用程式的崩潰不會影響到其他的。但這會影響性能，也使得程序間的通信變得很困難。
而應用程式域給我們提供了另外一種解決問題的辦法，一個程序可以包含多個應用程式域，每個應用程式域内的應用程式彼此隔離，避免了“為每一個應用程式啟動一個新程序”所帶來的開銷，之間的通信卻又比程序間通信有效率的多。
AppDomain提供了程序的好處，而且沒有程序帶來的大開銷。
App domains提供了一個适應于多種平台的一緻環境。.NET Framework意圖運作于Windows和其他可能的作業系統上，而不同的作業系統有完全不同的程序模型（process models），尤其小型裝置所使用的系統更是如此。讓app domains定義自己的程序模型，有助于.NET Framework跨越所有平台，提供一個一緻的環境。
六． .NET語言
1. Visual Basic.NET
在Windows世界裡，Visual Basic絕對是最流行的程式設計語言，Visual Basic.NET為這個廣泛使用的工具帶來的翻天覆地的變化。VB.NET建立于CLR（通用語言運作層）之上，是以這個語言的大部分成分已經被CLR有效界定了。實際上除了文法，你很難看得出如今的VB.NET和當年的VB有什麼相似之處了。從大的方面來講，VB.NET支援繼承、委托（Delegates）等新的特性，從小的方面來講，VB.NET數組的索引是從0開始了！
2. C++.NET
C++.NET其實應該說叫做
帶有受控擴充件（Managed Extensions）的C++。
C++是一門非常流行的語言，一門已被廣泛使用超過10年的語言。“提供某種方式使C++能夠和.NET Framework”是不可或缺的。然而同VB一樣，C++的語義同CLR的語義并非嚴格比對。更糟的是，微軟并不擁有C++，是以微軟并不能像對Visual Basic動大手術那樣也對C++來個脫胎換骨的修改。如果單方面修改這個語言使其和CLR相配，會遭到嚴重的抗議，但如果不提供“讓開發人員得以運用C++建立.NET Framework-based 應用程式”的方法，也會讓很多開發人員不痛快，至少，比爾蓋茨會很不痛快。
于是，微軟選擇開發一個相對于基本C++語言而言的擴充集。正式的名稱是Managed Extensions for C++。
新的C++定義了幾個新的關鍵字，他們均以兩個下劃線開頭，其中最重要的有如下所示：
__gc：指出某個type受垃圾回收機制的管制，換句話說這個關鍵字意味着他所聲明的types是個CTS reference type。
__value：指出某個types不受垃圾回收機制的管制，換句話說它所聲明的types是個CTS value type。
__interface：用以定義一個CTS interface type（接口型别）。
__box：将CTS value type轉換為reference type。
__unbox：将裝箱的(boxed)CTS value type轉回其原來形式。
__delegate：用以定義一個CTS delegate type（代理型别）。
基于以上的改變，Managed C++有了這麼一些特性：
Managed C++代碼和unmanaged C++代碼可共存于同一個程序中。
Managed C++允許完全通路CLR特性。
C++是Visual Studio.NET中唯一能直接編譯為原生代碼（native code）的語言。
C++語言不會壽終正寝，但它的作用将會收斂，可能還會收斂的相當厲害，作為一種“開發廣泛應用程式的首選工具”的日子已經終結。
3. C#
C#是一種有着和C文法相似的面向對象語言正如其名字所暗示的，C#是C語言家族中的一個新成員。C++從C衍化而來，嚴格的說，C++由于帶着C的包袱進而并不是一個嚴格的面向對象的語言。而C#不同，C#十足的面向對象，也并不帶來幾近殘酷的複雜度。對于擁有C++或者java背景的任何人來說，C#尤其平易近人。
C#和CLR的标準化微軟已經将C#和CLI（Common Language Infrastucture，通用語言基礎設施，CLR的一個子集）送出國際标準化團體ECMA，他們正朝着ECMA标準之路邁進。随同C#一同被送出并期望獲得标準化的還有：metadata（中繼資料）的文法和語義、MSIL(重命名後腳Common Intermediate Language，CIL，通用中介語言)，以及一部分.NET Framework類庫。
Sun曾經對Java做過類似的事情，但在最後一刻退縮了。Sun拒絕邁出這一步是因為不願放棄對Java的控制。從這一點上來說，C#的前景可能會值得期待一些。
Interfaces（接口）接口（interface）用來定義一種程式的協定。實作接口的類或者結構要與接口的定義嚴格一緻。有了這個協定，就可以抛開程式設計語言的限制（理論上）。接口可以從多個基接口繼承，而類或結構可以實作多個接口。接口可以包含方法、屬性、事件和索引器。接口本身不提供它所定義的成員的實作。接口隻指定實作該接口的類或接口必須提供的成員。
接口好比一種模版，這種模版定義了對象必須實作的方法，其目的就是讓這些方法可以作為接口執行個體被引用。接口不能被執行個體化。類可以實作多個接口并且通過這些實作的接口被索引。接口變量隻能索引實作該接口的類的執行個體。
屬性屬性可以說是C#語言的一個創新。當然你也可以說不是。不是的原因是它背後的實作實際上還是兩個函數--一個指派函數（get），一個取值函數(set)，這從它生成的中間語言代碼可以清晰地看到。是的原因是它的的确确在語言層面實作了面向對象程式設計一直以來對“屬性”這一OO風格的類的特殊接口的訴求。了解屬性的設計初衷是我們用好屬性這一工具的根本。C#不提倡将域的保護級别設為public而使使用者在類外任意操作--那樣太不OO,或者具體點說太不安全！對所有有必要在類外可見的域，C#推薦采用屬性來表達。屬性不表示存儲位置，這是屬性和域的根本性的差別。
Delegates（代理）、Event（事件）代理實作的是象c++等語言的指針功能，不同于函數指針，代理是一種面向對象、安全類型的。代理事派生于公共基類（system）的一種參考類型，方法被壓入一個代理中，對于執行個體方法被稱為執行個體的組成實體或關于執行個體的方法，而靜态方法，被稱為類的組成實體或類方法。代理的強大功能是它可以自動的比對方法，而不管其類型。
基于其上的，C#還定義了一個完全OO的東西，event（事件），形象地說，事件是對象用來“發出通知”的成員。根據你的需要，你可以訂閱某一個對象中的事件并響應該事件做出相應的處理。
七． .NET Framework類庫(Class Library)
名字空間（Namespace）和Com類庫的平面化結構不同的是，.NET 類庫被組織為一套具有層次結構的名字空間。每個名字空間可以包含types如classes和interfaces，以及其他次級名字空間（sub-namespaces）。整個體系的root名為System，每一個.NET Framework應用程式都回用上System所含的一些types。其他名字空間所含的types也可能被許多開發人員經常使用。System是基礎，但不是全部。
.NET 類庫的結構 八． 通路資料：ADO.NET
與資料打交道，如搜尋、更新和處理等，使軟體的基本任務。今天，大部分資料通常被存儲于某種類型的資料庫管理系統中（DBMS）中，通常是關系型資料庫（relational database）。開發人員需要某些機制，允許他們的應用程式通路這些資訊。Windows DNA有一組名為ActiveX資料對象（ActiveX Data Objects,ADO）的COM classes，解決了這個問題。NET Framework中的結局方案時ADO的激進更新版。
與 ADO 的早期版本和其他資料通路元件相比，ADO.NET 提供了若幹好處。這些好處分成以下幾個類别：
互操作性ADO.NET 應用程式可以利用 XML 的靈活性和廣泛接受性。由于 XML 是用于在網絡中傳輸資料集的格式，是以可以讀取 XML 格式的任何元件都可以處理資料。實際上，接收元件根本不必是 ADO.NET 元件：傳輸元件可以隻是将資料集傳輸給其目标，而不考慮接收元件的實作方式。目标元件可以是 Visual Studio 應用程式或無論用什麼工具實作的其他任何應用程式。唯一的要求是接收元件能夠讀取 XML。作為一項工業标準，XML 正是在謹記這種互操作性的情況下設計的。
可維護性在已部署系統的生存期中，适度的更改是可能的，但由于十分困難，是以很少嘗試進行實質的結構更改。這是很遺憾的，因為在事件的自然過程中，這種實質上的更改會變得很有必要。例如，當已部署的應用程式越來越受使用者歡迎時，增加的性能負荷可能需要進行結構更改。随着已部署的應用程式伺服器上的性能負荷的增長，系統資源會變得不足，并且響應時間或吞吐量會受到影響。面對該問題，軟體設計者可以選擇将伺服器的業務邏輯處理和使用者界面處理劃分到單獨計算機上的單獨層上。實際上，應用程式伺服器層将替換為兩層，緩解了系統資源缺乏。
該問題并不是要設計三層應用程式。相反，它是要在應用程式部署以後增加層數。如果原始應用程式使用資料集以 ADO.NET 實作，則該轉換很容易進行。請記住，當用兩層替換單個層時，将安排這兩層交換資訊。由于這些層可以通過 XML 格式的資料集傳輸資料，是以通訊相對較容易。
可程式設計性Visual Studio 中的 ADO.NET 資料元件以不同方式封裝資料通路功能，幫助您加快程式設計速度并減少犯錯幾率。例如，資料指令提取生成和執行 SQL 語句或存儲過程的任務。
強類型的資料集由這些工具生成的 ADO.NET 資料類導緻類型化資料集。這又使您可以通過已聲明類型的程式設計通路資料。最後，已聲明類型的資料集的代碼更安全，原因在于它提供對類型的編譯時檢查。例如，假定 AvailableCredit 表達為貨币值。如果程式員誤向 AvailableCredit 配置設定了字元串值，則環境會在編譯時向程式員報告該錯誤。當使用未聲明類型的資料集時，程式員直到運作時才會知道該錯誤。
對于不連接配接的應用程式，ADO.NET 資料庫提供的性能優于 ADO 不連接配接的記錄集。當使用 COM 封送在層間傳輸不連接配接的記錄集時，會因将記錄集内的值轉換為 COM 可識别的資料類型而導緻顯著的處理開銷。在 ADO.NET 中，這種資料類型轉換則沒有必要。
可伸縮性因為 Web 可以極大增加對資料的需求，是以可縮放性變得很關鍵。Internet 應用程式具有無限的潛在使用者供應。盡管應用程式可以很好地為十幾個使用者服務，但它可能不能向成百上千個（或幾百萬個）使用者提供同樣好的服務。使用資料庫鎖和資料庫連接配接之類資源的應用程式不能很好地為大量使用者服務，因為使用者對這些有限資源的需求最終将超出其供應。
ADO.NET 通過鼓勵程式員節省有限資源來實作可縮放性。由于所有 ADO.NET 應用程式都使用對資料的不連接配接通路，是以它不會在較長持續時間内保留資料庫鎖或活動資料庫連接配接。
下一代的SQL Server：YukonYukon是預定2005年供貨的SQL Server的新一代版本。內建了.NET Framework 2.0。SQL Server "Yukon"、.NET 技術和 Microsoft 開發者工具之間更深入的整合将提高開發人員産能和彈性，讓開發人員得以：
建置并維護強固、安全、可擴充的資料庫應用程式。開發人員将擁有一套适用于 Transact-SQL、XML 和 Multidimensional Expression (MDX) 的開發工具。與 Visual Studio? 開發環境的整合将提供更有效的實務和商業智能應用程式開發和偵錯。SQL Server "Yukon" 也将包含對 Transact-SQL 語言的強大改進。
從更多的開發彈性中獲益。借着内嵌在資料庫引擎的 Common Language Runtime (CLR)，開發人員将可以從多樣化的熟悉語言中選擇，用來開發資料庫應用程式，包括 Transact-SQL、Microsoft Visual Basic? .NET、Microsoft Visual C#? .NET 和 Microsoft Visual J#? .NET。此外，CLR 整合将透過使用者定義的型别和函式，為開發人員提供更多的彈性。CLR 也将提供機會，讓使用協力廠商的程式代碼能夠快速開發資料庫應用程式。
跨任一種平台、應用程式或裝置以共享資料。對于諸如原生 XML 支援、使用者定義的資料型别和 XQuery 的改進将讓組織完美連接配接内部和外部系統。SQL Server "Yukon" 将提供關系型和 XML 資料的原生支援，讓企業得以最适合其需要的格式儲存、管理和分析資料。對于現有和新出的開放标準，如超文字傳輸協定 (HTTP)、XML、簡單對象存取協定 (SOAP)、XQuery 和 XML 結構描述定義 (XSD) 的支援，也将加速橫跨已擴充之企業系統之間的通訊。
九． 開發Windows相關應用
有些時候，browser-based應用程式似乎接管了這個世界。盡管開發人員曾經投入大量時間，徹底搞清楚Windows GUI是怎麼回事，他們現在也為HTML和Javascript細節留下了豆大的汗珠。對于現在軟體來說，浏覽器已經成了新的預設界面。
但是Windows GUIs依然不可小觑。浏覽器雖然占據支配地位，但直接通路螢幕象素的應用程式，并沒有消亡。.NET Framework設計者提供了一套嶄新的classes，是CLR-based應用程式能夠建構Windows GUIs。包含于System.Windows.Forms名字空間中的這套classes通常被稱為
Windows Forms。
1. 本地應用程式
典型的GUI模型是一個form，帶有負責響應事件的代碼。Windows Forms遵循這種傳統模型。每一個form都是Form class的一個實體，而接受和派發事件的消息循環，由Application class提供。Form class的每一個實體都有一大套properties，用來控制form在螢幕上顯示的外觀。forms通常包含其他class，統稱為
Windows Forms控件（controls），他們一般用于展示某種輸出，接受使用者的某些輸入，抑或兼而有之。空間也擁有properties，yon與定制其外觀。Forms和controls都可以相應events，并做出某種動作。
另一個相關的技術就是
GDI+了
GDI+ 是 Microsoft Windows XP以及後續windows作業系統的子系統，同時又是.net提供的一種新的簡單、快速的圖形圖象開發技術。顧名思義，GDI+ 是 GDI（Windows 早期版本提供的圖形裝置接口）的後續版本。GDI+ 是一種應用程式程式設計接口 (API)，通過一套部署為托管代碼的類來展現。這套類被稱為 GDI+ 的“托管類接口”。
程式員可利用GDI+這樣的圖形裝置接口在螢幕或列印機上顯示資訊，而不需要考慮特定顯示裝置的具體情況。應用程式的程式員調用GDI+類提供的方法，而這些方法又反過來調用特定的裝置驅動程式。GDI+ 将應用程式與圖形硬體隔離，而正是這種隔離允許開發人員建立裝置無關的應用程式。
2. 智能用戶端技術
Smart Client是什麼簡而言之，Smart Client智能用戶端就是這樣一種
一個可擴充的能內建不同應用的桌面應用程式：它可以無接觸部署、即需即裝、動态加載，XCopy即可運作而無須修改系統資料庫，可以動态更新、自動更新，可以友善的經Web運作而不用擔心防火牆問題并可以友善的離線運用，友善的連接配接WebServices的Windows應用程式。 Smart Client的特點 動态加載，即需即裝應用程式的各個構件之間的互相調用并不采用直接引用的方式，而是采用動态加載，即需即裝的方式，有效地降低了對系統資源的消耗。應用軟體開發商可根據企業應用系統的公共接口進行開發，然後将應用元件釋出在企業的伺服器上，用戶端應用程式将自動發現并加載該應用元件。
更松散的耦合由于上面第一點所言構件之間的互相調用并不采用直接引用方式，這樣系統實作的更松散的耦合，為應用程式更新更新提供了友善。
進一步的子產品化由于應用程式的松散耦合特性，使得系統的進一步子產品化成為了可能，新功能、新特性的加入隻需要開發出符合接口定義的新子產品并添加連接配接即可。而無須修改重編譯現有的程式。
零接觸部署安裝時隻要将一個主程式檔案下載下傳到本地，直接運作即可，無須改變系統資料庫或共享的系統元件，其他應用元件将在第一次運作時自動下載下傳。
網絡加載應用程式元件Smart Client的應用程式可以很友善的從網絡伺服器加載應用程式，而且因為程式及加載是從80端口實作，故無須考慮防火牆問題，這樣為企業系統的集中管理提供了友善。
自動更新隻需将新版本的程式釋出在伺服器上，由用戶端自動發現最新版本的程式和應用元件，并自動下載下傳和更新。
線上與離線均可使用的應用程式Smart Client應用程式盡管使用網絡加載程式集，但一旦加載之後，程式集便被緩存到了本地。當使用者至少啟動了一次應用程式後，其裝配就被下載下傳和緩存到本地記憶體中了，是以使用者就可以離線運作你的智能用戶端了（通過轉換浏覽器到離線工作狀态），假設應用程式不需要永久通路Web services或一個共享的資料庫就可以運作。
建構智能用戶端的最大的好處就是可以離線使用。盡管業務之間的聯系越來越緊密，但我們仍不能給企業應用程式提供始終連續的連接配接。離線式工作方式可以在你重新線上時，自動接收資料和應用程式更新，這種特征是人們很想得到的，但在.NET前，這是很難實作的。同胖用戶端一樣，智能用戶端給用戶端分布大量的處理，這就為伺服器免除了它在一個基于Web的應用程式中需要承擔的負荷。最後，智能用戶端采取一種使用者希望應用程式采取的工作方式——允許快速資料存取和管理，而不需要不必要的螢幕更新。
個性化使用者界面使用者可根據喜好自行設定用戶端應用程式，配置資訊将被儲存到伺服器上。
與WebServices的完美內建Smart Client應用程式可以與WebServices友善的內建應用，這樣便可以輕松享受C/S應用程式的完美使用者體驗而不需擔心防火牆等等的一系列問題。
Smart Client的優勢盡管有大量的廣告，但瘦Web解決方案并沒必要成為所有企業應用程式的未來。不要丢棄用WinForms來建構企業應用程式這種想法，因為企業應用需要集中的分布。下面的這張表格描述了Smart Client和其他解決方案之間的對比：
表 1 比較幾者
通過将智能用戶端的功能和Web應用程式的功能進行比較，可以簡化你的決策過程。
Smart Client的工作模型 圖1. 智能用戶端的工作模型
應用程式加載器用HTTP從Web伺服器上的一個虛拟目錄來通路和下載下傳裝配。下載下傳後，裝配被緩存起來，隻有需要的時候才執行它們。
3. Windows的未來：Longhorn
2003年5月，微軟公司在新奧爾良Windows硬體開發人員論會上（WinHEC），進行了Windows下一作業系統 Longhorn的内部首映。微軟公司在論會上介紹了Longhorn作業系統的發展計劃，并且認為Longhorn是Windows 95作業系統以來，繼Windows XP作業系統之後，功能最強大，性能最突出的桌面作業系統。
Longhorn的關鍵技術： 應用程式程式設計模型“WinFX”。對“.NET Framework”的程式設計模型的擴充，微軟表示：“将大幅提高開發人員的開發效率和應用程式的安全性”。你甚至可以認為，.NET Framework将更名為WinFX，成為Longhorn主要API。
圖形技術“Avalon”。是使用者界面、文檔和用于顯示多媒體的綜合架構。
存儲技術“WinFS”。将強化檢索、關聯和使用資訊的手段。根據特定需求而采用相應的應用程式資料結構。
通信技術“Indigo”。對Web服務提供支援，能夠交換高安全性的資訊，并能進行互連。
十． 開發Web相關應用
經由Web來通路軟體已經是一件稀松平常的事情了。大多數新式企業應用程式至少提供浏覽器界面的選項，甚至隻提供浏覽器界面。鑒于此，如果一個應用平台沒有為建構Web-based的軟體提供一級支援，那簡直注定要失敗。事實上，通過Web使用軟體的方式也在不斷變化之中，通過浏覽器來和使用者交流當然重要，但Web Services也閃亮登場了。Web已經從單純的眼球驅動的世界，擴張到也由應用程式驅動的世界。
ASP.NET是.NET Framework用于建構Web相關應用的首要基礎。作為.NET Framework類庫的一個組成，它同時支援建立“浏覽器應用”和“Web Services應用”，兩者都依賴共通的基礎設施。
1. 浏覽器應用程式
從前的ASP：意大利面條 Asp.net的新性能：
代碼分離這個功能又叫做代碼隐藏(Code-behind)，将代碼放在單獨的檔案中，你将不會再看到意大利面條似的代碼了。
（類似）事件驅動模型ASP.NET實作了類似事件驅動模型這樣的機制，但由于HTTP是一個無狀态的協定，還隻能稱之為“類似”。
Web controlsWeb controls使建立forms 和HTML controls.的工作将會變得簡單易行。例如，在ASP中典型的選擇框/ select box裡，你不得不建立一個循環以便讓控制系統裝入資料。但在ASP.net裡，你将會擁有一個"data-bound"，這意味着它會與資料源連接配接，并會自動裝入資料。
語言支援asp.net支援多種語言，它的預設語言将是：visual basic而不是vbscript，這意味着我們可以擺脫vbscript的語言限制，我們的代碼将是編譯後運作的（而不是原來的解釋執行）。
更好的代碼控制對于COM對象不再需要再在伺服器上注冊的這個功能我們是非常喜愛的。但是通過這種過程簡化，你再也不能夠在你的伺服器上運作 另外一個DLL版本，并且代碼相當保密，這意味着，如果沒有正确的開發工具和源代碼，很難改變代碼。
更好的更新能力此系統建成，本身有着一定的特性，以改進多處理器和串環境中的性能。例如，session state 能夠通過單獨的處理器來維持，在一個單獨的機器上，甚至在資料庫中允許交叉的伺服器會話。
2. Web Services應用
ASP.NET中的Web Serivces應用程式依賴.asmx網頁就像迄今所描述的浏覽器應用程式一樣，伺服器端的ASP.NET Web Services應用程式也依賴網頁。這些網頁所在的檔案都有一個.asmx擴充名，其内不含任何的HTML，隻是一些代碼。這是因為伺服器僅僅是被軟體通路，而非被人通路，是以無需HTML，換句話說，伺服器并不展示使用者界面。
Web Method attribute用以将Method開放為Web Services為了将一個包含于.asmx檔案内的method開放為一個Web Service，你唯一要做的事情就是在method的聲明方面插入Web Method attribute，這樣就可以了。一旦檔案被建議，這個attribute将被存儲在“為此而産生之裝配件”的metadata中，就像所有其他特性一樣。他向ASP.NET技術設施提供了一個信号：這個method應該可以被Web Service通路。
Web Service用戶端依賴proxies(代理)用戶端為了使用Web Services，開發人員必須首先建立一個開放了相同Method的proxy class。利用這個代理類的資訊，用戶端就知道該如何去調用并享受服務。
.NET Remoting .NET Remoting 不屬于ASP.NET的技術範疇，但提供了與Web Services相似的功能。.NET Remoting與Web Services的比較：
都是采用了SOAP協定 .NET Remoting僅限用于通信雙方都是.NET平台的情況下，而Web Services緻力于提供一個不同平台下應用軟體不同的能力。
在通信雙方都是.NET平台的前提下，
.NET Remoting提供了更高的性能。
十一． 基于Smart Device的開發
何為Smart DeviceSmart Device的中文意思就是“智能裝置”，泛指Smart Phone、Pocket PC等使用了Windows CE作業系統的移動的、嵌入式的或者具有人機互動功能的電子産品。Pocket PC(以下簡稱PPC)想必大家已經都很熟悉了，現在國内已經有相當的使用者群體。國際大廠如卡西歐、康柏等的産品早已進入中國市場，國内公司如聯想也積極推出類似産品，争奪這片未來很有潛力的市場。
何為.NET Compact Framework微軟為了實施.NET戰略，在一年前推出了面向Windows平台的.NET Framework 1.0，我想這一點大家已經很熟悉了。在2003年4月份，微軟又推出了Windows Server 2003和Visual Studio .NET 2003。其中Windows Server 2003中更是內建了.NET Framework 1.1，而VS.NET 2003中也增加了不少新鮮的開發模版。
.NET Compact Framework的中文名稱就是.NET Framework精簡版。簡單來說如果Windows CE作業系統是嵌入式或移動電子裝置上的Windows，那麼.NET Compact Framework就是這些裝置上的.NET Framework。實際上.NET Compact Framework是.NET Framework針對嵌入式或移動電子裝置的子集和補充。.NET Compact Framework有兩個主要元件：公共語言運作庫和 .NET Compact Framework類庫。
公共語言運作庫公共語言運作庫提供了管理 .NET Compact Framework代碼的執行環境。代碼管理的形式可以是記憶體管理、線程管理、安全性管理、代碼驗證和編譯以及其他系統服務。
運作時是為了增強性能而設計的。它使用實時 (JIT) 編譯的方法，使托管代碼能夠以運作應用程式的平台的本機語言運作。這樣，您就可以建立适用于多種平台的應用程式，而不用再擔心如何分别為每個平台重新編譯或重新生成可執行程式了。
即使您的移動應用程式與托管代碼一樣都是用 Visual Basic .NET 或 C# .NET 編寫的，仍然可以內建存儲在動态連結庫（DLL，包括 Windows CE API）外部的功能和子例程。.NET Compact Framework提供的資料類型以及對結構的支援使您能夠輕松地将 Windows CE API 的功能內建到您的應用程式中。
.NET Compact Framework類庫.NET Compact Framework類庫是與公共語言運作庫緊密內建的可重複使用類的集合。您的應用程式将利用這些庫來派生出所需的功能。就像其他面向對象的類庫一樣，.NET Compact Framework類型可用于完成許多常見的程式設計任務，包括界面設計、利用 XML、資料庫通路、線程管理和檔案輸入/輸出等。
.NET Compact Framework 是.NET Framework完全版的一個相容子集由于.NET Compact Framework是.NET Framework完整版的一個相容子集，這就意味着，您可以使用您熟悉的VB.NET或者C#友善地為Pocket PC開發應用程式，并且您不需要考慮該PPC的處理器是ARM、MIPS還是其他的什麼處理器，更妙的是，這應用程式在您的桌上型電腦上一樣能很好的正常工作！
十二． Office的擴充應用
将 Office 用作業務解決方案平台開發人員可以将 Microsoft Office 2003 應用程式用作建立自定義解決方案的平台。Office 使開發人員可以利用一套豐富的預置功能。
将 Microsoft Office Word 2003 或 Microsoft Office Excel 2003 用作解決方案前端使開發人員可以利用熟悉的使用者界面和強大的工具，例如拼寫檢查、多語言支援、更改跟蹤和資料透視表。另一個優點是脫機使用解決方案的用戶端部分，這與使用基于 Web 的結構相比，更容易實作複雜的解決方案。
用于 Microsoft Office 系統的 Visual Studio 工具用于 Microsoft Office 系統的 Microsoft Visual Studio 工具可以幫助您建立解決方案，方法是使用 Visual Basic .NET 和 Visual C# 擴充 Word 2003 文檔和 Excel 2003 工作簿。用于 Office 的 Visual Studio 工具中包括新的 Visual Studio .NET 項目，用于建立 Word 文檔、Word 模闆和 Excel 工作簿的後端代碼。這些項目包含：
對項目主要的主互操作程式集的引用 對所需系統元件的引用 項目初始化 使開發人員可以快速入門的安全設定 用于 Microsoft Office 系統的 Visual Studio 工具可以幫助您快速建立解決方案，它利用了每個應用程式的内置功能并提供以下優點：
Word 和 Excel 的後端托管代碼用于 Office 的 Visual Studio 工具中包括 Visual Studio .NET 項目，以幫助您在 Visual Studio .NET 環境中用 Visual Basic 和 C# 編寫 Word 和 Excel 的後端托管代碼。您的代碼對文檔或工作簿中發生的事件進行響應。有關更多資訊，請參見使用托管代碼擴充的 Office 解決方案的結構。
部署和維護在部署使用托管代碼擴充的 Office 解決方案時，可以将編譯代碼和文檔存儲在共享位置以便于維護；也可以将程式集和文檔的副本分發給每個使用者以适應移動工作方式。
安全使用由 Microsoft .NET Framework 提供的安全功能實作安全。對于使用用于 Microsoft Office 系統的 Visual Studio 工具建立的程式集，預設政策是不允許任何程式集運作，這有助于保護使用者不受病毒和其他惡意代碼的攻擊。在最終使用者可以利用文檔的托管代碼擴充之前，管理者必須顯式對程式集授予完全信任。
脫機通路如果将程式集部署到可以用 Web 位址（http:// 或 https://）通路的網絡位置，可以使用 Internet Explorer 功能将該程式集緩存到本地計算機上。這使本地文檔可以在未連接配接到網絡時使用該程式集。如果将文檔和程式集的本地副本同時部署到每個使用者，就無須考慮網絡連接配接問題了。
解決方案的典型結構下面的關系圖闡釋了一個典型的解決方案結構。該關系圖的上部顯示從最終使用者角度出發的運作時體驗。
運作時涉及最終使用者的步驟：
1．最終使用者打開具有托管代碼擴充（指向托管代碼程式集的自定義屬性）的文檔或工作簿。
2．文檔或工作簿從共享網絡位置下載下傳編譯後的程式集。
3．程式集響應文檔或工作簿中的事件。
該關系圖的下部是從開發人員和（可選）設計人員角度出發的設計時體驗。
設計時涉及開發人員和設計人員的步驟：
1．開發人員在 Visual Studio .NET 中建立 Microsoft Office 2003 項目。該項目包括文檔和在該文檔後端運作的程式集。該文檔可以是已存在的文檔（多半是由設計人員建立的），或者也可以随項目建立一個新文檔。
2．設計人員（建立該項目的開發人員或其他人）為最終使用者建立該文檔的最後外觀。
由于開發人員主要在 Visual Studio .NET 中工作，最終使用者主要在 Microsoft Office 2003 中工作，是以可以用
兩種方式了解使用托管代碼擴充的 Office 解決方案。| 開發人員的角度 | 最終使用者的角度 |
| 開發人員使用 Visual Studio .NET 編寫 Word 和 Excel 可以通路的代碼。 盡管開發人員似乎在建立一個運作 Word 或 Excel 的可執行檔案,但實際的工作方式卻不是這樣的。文檔與一個程式集相關聯，并包含指向該程式集的指針。打開文檔時，Word 或 Excel 定位該程式集并針對所有已處理的事件運作代碼。 | 使用解決方案的人隻須同打開任何其他 Office 檔案一樣打開文檔或工作簿（或從模闆建立新文檔）。 程式集在文檔或工作簿中提供自定義功能，例如用目前資料自動填充它，或顯示對話框以請求輸入資訊。該代碼執行這些動作時，使用者并不知道此文檔與其他任何 Office 文檔有何不同。 |
十三． .NET My Services
基于XML Web Service的下一代計算模式已經為業界認同，作為産品線較長的軟體廠商，Microsoft已經在通向下一代的道路上領先了。繼推出了XML Web Service的各種相關産品之後，Microsoft最近又釋出了自己的基于XML Web Service的平台，這就是Microsoft My Services。在過去很長一段時間裡，My Services曾以其開發代碼Hailstorm為人所關注。
資訊溝通的挑戰雖然在過去的25年裡，資訊技術的非凡價值已經得到了使用者的普遍認同，但至今仍遠沒有發展成熟，在很多方面有待加強和提高。各種裝置和應用程式各自為政，并不考慮與周圍世界的聯系。
由此造成的後果是，每一種裝置、每一種應用程式乃至每一個Web站點都有自己的一套規則和使用方法，造成使用者的困惑。例如，我們向PC中輸入朋友的電話号碼需要按照一定順序敲擊鍵盤，而向Palm Pilot、Pocket PC或者行動電話中輸入同樣的電話号碼所需的方法則完全不同。是以，我們不得不從最基本的字元輸入法開始，學習使用每一種裝置。
雖然我們為資訊化的進步而驕傲，但我們并沒有真正掌握身邊的資訊和裝置，不難發現，我們的重要資訊散落在技術空間的成百上千個角落裡: 在某個PC的應用程式裡、機關的某個伺服器裡、Cookie裡以及網站的使用者跟蹤表格裡……行動電話中存儲的電話号碼并不為電子郵件程式所知，因為這2種技術無法了解對方的語言。
如果您搬家，改變了住址，您往往不得不在每一個Web站點中更新您的送貨位址，如果萬一某次疏忽了，“友善的”Internet會帶給您一次不大不小的教訓。您可能并不能擁有您的個人資訊，它經常會被遺忘在某個Internet孤島上。各種應用、Web站點以及服務的孤立特性使得各種技術很難有效地協同工作。如果您在網上訂了機票，因為缺乏有效的溝通方式，Web站點很難将您的行程自動同步到日程安排應用程式裡，即使實作了，通訊的雙方也不能保證客戶是同一個人。
也許我們不得不承認，現在，我們實際上是在被動地去适應資訊技術，在享受新技術的成果之前，我們首先要适應被強加的新規則。這種不便事實上限制了更有創造性的新技術和新産品的發展和應用。
初識.NET My Services按照Microsoft的定義，.NET My Services是一套以使用者為中心的軟體服務結構架構，是若幹各種用途的XML Web services的集合。Microsoft .NET My Services能夠簡化将現有的各種孤立應用內建的工作。最大的變化在于，.NET My Services是面向使用者的，而不是面向特定裝置或應用的。它使使用者能夠真正控制自己的資訊、保護私人資料，使得個性化服務更易實作。得益于Microsoft .NET技術，.NET My Services能夠使各種裝置、應用和服務有效地協同工作，而使用者可以控制誰可以通路自己的資訊，具有哪種層次的通路權限，以及有效期限等。
面向使用者，或者說以使用者為中心實際上是以使用者資料為中心。是以，.NET My Services對使用者資料的安全非常重視，通過Microsoft .NET Passport來保證資料的安全、完整和私密性。在任何應用需要通路使用者資料時，都需要使用者進行确認。
以訂機票為例，通過.NET My Services，線上旅行票務預訂服務可以自動通路使用者的個人意向資訊和付款服務(經過使用者的确認)，如果使用者是進行商務旅行，則線上旅行票務預訂服務還要經過.NET My Services的個體群屬關系服務确定使用者在公司的位置、從屬關系，并根據公司的商務旅行政策進行比對，使得航班級别與日程安排能夠符合公司的有關規定。一旦標明了航班，旅行服務還能自動選擇相應的日程安排服務，自動更新路線資訊，并在航班延誤時進行通知。通過.NET My Services，您還可以共享出日程安排，使接待方随時了解您的動向。而您的日程安排資訊可以通過您的PC、其他人的PC、某台智能電話、PDA以及任何智能資訊裝置來通路。
.NET My Services工作原理.NET My Services實際上由3部分組成，即身份認證(.NET Passport)、消息傳遞(SOAP)以及資料描述(XML)。圖2顯示了應用程式使用.NET My Services通路使用者資料的過程。
.NET Passport是使用Kerberos協定來完成身份認證的，Windows 2000和Windows XP都使用了Kerberos協定。簡單地說，Kerberos通過集中存儲的安全資訊和分布式的“tickets”來實作使用者身份認證。具體而言，.NET My Services通過如下步驟實作使用者身份驗證。
使用者開啟用戶端應用程式或浏覽器，打開登入界面，并輸入使用者名和密碼。
登入動作引發用戶端應用程式或網站向.NET Passport請求一個登入确認證明(即“ticket-granting-ticket”，TGT)。
.NET Passport驗證使用者密碼，頒發TGT，确認登入已經成功。在滿足一定安全限制條款的前提下，該TGT在一定時期内被緩存。
用戶端應用程式或網站向.NET Passport(它這時所扮演的角色是Kerberos中的“證明頒發伺服器”)送出TGT，同時請求頒發一個“會話證明” (即session ticket)。
.NET Passport使用TGT來驗證用戶端的身份是否正确（即是否有效），确認後向相應的Web Service頒發會話證明。
用戶端向所請求的Web Service送出會話證明，經确認後，用戶端與Web Service的資訊交換展開，所有資料都經由該會話證明加密進而確定安全。
SOAPSOAP是基于XML的協定，一條SOAP消息由3部分組成。首先是信封(envelope)，用來描述消息的結構、内容以及處理方法。其次是一套規則，描述處理不同類型資料的方法。最後是關于原過程調用及其相應方式的約定。
通過SOAP，應用程式不僅能夠實作資料共享，還能夠調用遠端應用對象的方法和屬性，而不必了解對方的應用程式結構，也不需要特定的二進制代碼、運作時庫以及任何平台相關的條件。 .NET My Services通過SOAP協定來通路Web Service。
XML.NET My Services的最底層是XML，一種基于SGML的文本形式的标記語言。XML具有可自描述，以資料為中心的優秀特性。關于XML的相關資料已經有很多，在此不多贅述。
十四． .NET的開發工具(Visual Studio.NET)
在2001年亞特蘭大的Tech Ed 2001大會上，比爾·蓋茨對熱忱的開發人員介紹了Microsoft最新的開發環境。不過，
Visual Studio .NET作為NET平台的基石，不僅僅是一個開發環境。Visual Studio.NET是用開發人員用于建立應用程式的技術建構的。
由于通用語言運作時（Common Language Runtime），Visual Studio.NET為C++、C#和VB程式員提供了通用的開發環境。Jscript程式員在建立ASP.NET 和 Web服務應用程式時将得到Visual Studio.NET有限的支援。而XML開發人員将非常喜歡它對XML文檔、XML大綱和XSL轉換的強大支援。
實踐Visual Studio .NET的設定很容易。安裝程式将帶你經過主要的3個步驟：更新系統元件，安裝 .NET架構，增加Visual Studio .NET。如果喜歡完全安裝，你還将得到C++及其類庫和工具，C#和VB。你還将獲得Crystal Reports、伺服器元件及用于重新分布應用程式的工具。在環境調用時，将出現一個與浏覽器類似的視窗，你會被帶到開始頁，此頁包含了對線上資源、更新、新聞和下載下傳等等内容的連結。下載下傳連結特别有用，因為它将你直接帶到Microsoft的MSDN區，在那裡可以獲得最新的軟體工具包、源代碼示例及參考實作。Web主機連結帶給你一個包含了支援ASP.NET的公司清單的網頁。如同Microsoft所說: “每個公司給你提供一個實驗用測試場所”。另一個連結使你能夠根據你目前的開發類型修改造型。例如，Web開發人員可以選擇InterDev造型，設定類似于Visual Studio 6的鍵盤和視窗布局，設定幫助檔案過濾器——它隻彈出與網際網路開發相關的文檔。 Visual Studio.NET充分利用了螢幕空間。首先，可以在螢幕上打開多個視窗，然後通過跳格鍵快速在視窗間切換。還可在螢幕上固定視窗，或将它們泊位到螢幕任何一邊，如屬性視窗。當滑鼠在泊位視窗滑過時，它立刻滑動到螢幕上。這就使得在導航視窗、工具條、屬性檢測器和編輯器間進行轉換變得容易。環境是可配置的。從工具菜單中，可以為所有環境修改正常設定，并可以為每種語言設定選項。也就是說，如果你需要在VB和C#間進行轉換，這種設定功能就很有用。另外除了控制Visual Studio.NET的開啟行為，你還可定制編輯器，設定字型和顔色，為工程和方案設定預設存儲位置。開發環境的特性包括對調試器和造型進行了改進，出現了支援新部署模型的工具，提高了源代碼控制等等。作為快速參考，附表總結了其中的主要特性。
Visual Studio為Visual Studio.NET所支援的所有語言提供了一個統一的代碼編輯器，而對每種語言又支援特定的特性。編輯器有了很大改進，如字提示、遞增搜尋、代碼大綱、重疊文本、行号、分色顯示和快捷鍵。編輯器還提供了許多特定于語言的特性，如它能在輸入時完成原型和函數調用。
除了程式設計語言，編輯器還支援HTML文檔、層疊樣式表單，甚至XML的開發。事實上，XML文檔中的關鍵字，如XML聲明和屬性，已經通過顔色高亮度顯示。而且，編輯器提供了源視圖和資料視圖。在資料視圖中，文檔的結構在左側視窗中顯示出來。當在這種層次中選擇一個XML元素時，視窗右部的表顯示它的子元素，使你能夠挖掘它的元素資料。然而，反常的是，并不是所有XML元素都能調入到資料視圖中。具有不可預測結構的文檔，在試圖調入到資料視中時，編輯器将不知所措。
另一個令人愉快的是，Visual Studio .NET使你能夠根據文檔執行個體建立XML大綱。預設情況下文檔執行個體在文檔源視圖中打開。你可仍處于源視或轉換到資料視圖中，然後在視圖中右擊，從彈出的菜單中選擇建立大綱。接着出現一個對話框，讓你輸入大綱文檔的名稱。一旦大綱建立了，對它的引用将插入到原始文檔執行個體中。對于那些不願從頭編寫XML大綱的人來說，Visual Studio.NET使你能夠跳過開頭。
工程和解決方案另一個友善的特性是解決方案。一個給定的方案涉及到多個工程。解決方案像獨立的工程一樣，在解決方案視窗中進行管理。是以，可以通路、建立、編輯和删除為解決方案定義的任何工程中的單個檔案。
在設定獨立工程時，VB、C#和C++程式員通常會發現此過程是很省力的。用VB在幾分鐘内可以建立一個ASP.NET應用程式。環境自動在本地Web伺服器上建立虛拟目錄，增加aspx 和 global.asax檔案、CSS樣式表單、一些部件、查找檔案及一個包含了工程配置資訊的XML文檔——Web.config。你所做的隻是在Web浏覽器中執行aspx文檔以運作應用程式。
另一方面，Jscript開發人員将面臨困難，因為Jscript沒有完全與Microsoft開發環境（MDE）內建起來。這意味着必須手動設定虛拟目錄，手工建立、管理許多檔案。
語言變化如同它所支援的平台一樣，Visual Studio .Net在程式設計方面也發生了大變化。由于VB與通用語言運作時的內建，VB程式員将感到巨大變化。你可能需要重新從頭設計整個代碼塊。對于初學者來說，繼承性和多态性意味着VB最終會成為真正的面向對象的程式語言。VB現在可以超越方法，重載方法調用。VB還引入了結構化異常處理，支援類似于COM的接口和多線程。另外，很多語言成分被抛棄了，有一些被新屬性、方法和函數所代替。
Jscript也可以發現Jscript發生了重大變化。由于編譯語言的本質，所有Jscript變量現在必須聲明。還引入了資料類型。以前，Jscript程式員建立沒有與資料相關連的變量。然而，現在.NET 應用程式特别要求為變量指定資料類型。這樣做不會丢下Jscript程式員，但資料類型的引入使Jscript程式員遇到了以前沒有遇到過的問題（如類型相容性）。 Jscript還引入了類、函數重載、對屬性的擷取和設定。增加的其他語言特性包括常量聲明、枚舉器和新的導入聲明。它肯定不是上一代的腳本語言。
Visual Studio .NET是特性非常豐富的開發環境，通用語言的支援能力使開發人員能在C++、VB和C#間自由轉換。編輯器還支援XML文檔、XML大綱、HTML和CSS的建立。調試器和profiler有所增強，新的工具支援部署、源代碼控制和其他許多特性。當然，對可能的.NET程式員還有很多重要變化。這就是為什麼無法想象沒有Visual Studio如何建立.NET應用程式的原因。
十五． 結語
.NET為開發者提供了更好、更有威力的環境.NET的初創，是微軟向前邁出的一大步。通過提供一個開發Windows應用程式的新基礎，這家公司幾乎是強迫開發人員開始攀登一個冗長的學習曲線。然而Web Services、.NET Framework、.NET My Services以及.NET其他部分所帶來的好處。這個嶄新的開發環境更加現在，并且提供更多服務。一旦開發人員掌握了.NET核心技術，他們的生産力将會大大提高；運用内建的Web Services支援，便可開發出全新類型的應用程式。最終，.NET很可能達到終極目标：以最少的時間，開發出最好的軟體。
為了獲得更強大的威力，必須接受改變但是，為了獲得這些強大的威力，開發人員必須忍受的負面影響是：大幅度的變化。Windows開發人員必須學習許多新語言特性（如果學習的是C#，那甚至是門全新語言）、一個（至少某部分）既大又新的标準類庫，以及五花八門諸如Web services等等的新概念。某些開發人員甚至會出現信心挫折，因為他們原有的很大一部分知識失去了作用。例如，除非你要和現有代碼進行互動，否則COM在..NET Framework之中派不上什麼用場，是以，微軟環境中的軟體開發人員千辛萬苦才學得的COM細節知識，對于開發Framework-based應用程式已經沒有什麼意義。随着.NET Framework的Windows Forms的引入，現有的GUI技術變得價值不大。即使在資料通路方面，也有相當大的不同，因為ADO已經被ADO.NET所取代。
然而，抱怨是沒有任何意義的，對于希望在這個環境下工作的開發人員來說，唯一的選擇是投入必要的時間，開始和.NET進行一番搏鬥，因為.NET是在Windows上開發應用程式的未來。
随着奶酪的變化而變化， 并享受變化！