.NET
Colin Fahey
1. 定義.NET
任期“.NET”指下列收集技術：
（ 1 ） Framework Class Library (FCL)
（ 2 ） Intermediate Language (IL)
（ 3 ） Common Language Runtime (CLR)
1.1 Framework Class Library (FCL)
該Framework Class Library (FCL)是一個廣泛的班，以支持：
*容器(Array, String, List, ...)
*多線程（線程，線程池）
*網絡（套接字，協議，客戶端，服務器）
*文件操作
*數據流
*解析（正則表達式， XML處理）
*數學行動
*異常處理
*語言功能（反思，堆棧跟踪，動態代碼）
該Framework Class Library (FCL)是實施了很多不同的平台( Windows, Linux, MacOS, ... ) 。
因此，一個單一的計劃使用Framework Class Library (FCL)可以發展無顯著的知識之間的分歧目標平台。
該Framework Class Library (FCL)包含有用的模式的基本概念計算機科學（如“線” ， “插座” ， “流”等） 。
在某種意義上， Framework Class Library (FCL)給每個支持的操作系統一個現代化，高層次的，一致的編程接口。
該Framework Class Library (FCL)是其中一個最先進，全面，統一設計，證據確鑿的收藏品的功能和數據類型提供給程序員。
不幸的是，以下多媒體方面是不是部分的Framework Class Library (FCL) ：錄音，音頻播放，視頻錄製，視頻播放，三維渲染，操縱桿投入，設備控制( CD/DVD, ... )等。
Microsoft有一個.NET版本的DirectX圖書館為他們Windows作業系統。
有C#包裝OpenGL ， OpenAL ， GLUT ， SDL等，但，這是不太方便，有這樣的多媒體功能被包括在核心Framework Class Library (FCL) ，並包括在最終用戶“的運行時”庫。
其中一個問題，發展中國家的程序使用，特別是圖書館的是，打算訂定的最終用戶將需要支持選定的圖書館。
如果沒有方便的下載和安裝必要的圖書館，最終用戶可能會選擇不使用的程序，要求這些圖書館。
最終用戶也可能不願意等待一個圖書館下載從線上的位置。
如果某個程序的開發需要一個最終用戶尋找，購買和安裝的圖書館，所有的援助，從某個特定程序，然後最終用戶可能會選擇不使用該程序。
例如，許多開放源代碼項目，要求最終用戶尋找，下載和安裝，許多不同的圖書館從其他開放源代碼項目（例如： openssl ， zlib ， libpng ， libjpg ， glut ， ...),這是時間消費性，複雜性，令人沮喪，並可能導致最終用戶的選擇，以尋求其他的程序或產品。
該“Windows Update”服務，顯然有利於部署版本1.1的.NET運行時間圖書館Windows用戶。
這些運行時間圖書館包括與Windows XP作業系統。
因此，創造Windows程序需要.NET 1.1似乎是完全合理的。
此外，運行時間圖書館Microsoft's實現的.NET Framework Class Library (FCL)可以自由地重新分配，使開發人員可以供應這些圖書館向最終用戶誰不已經有圖書館。
該Windows Vista作業系統的船舶與.NET 3.0運行時間圖書館（組合的.NET Framework Class Libraries和幾個新的圖書館，如“Windows Presentation Foundation” (WPF) ） 。
因此，部署.NET 2.0和.NET 3.0節目Windows Vista並不要求安裝工人為.NET運行時間圖書館。
1.2 Intermediate Language (IL)
該Intermediate Language (IL)是一個很小的一套簡單，處理器的獨立，操作系統獨立的指示，足以完全表達數據的結構與功能很多不同的高層次的編程語言( C++, C#, F#, Visual Basic, Java, Ocaml, ... ) 。
源代碼的書面在一個高層次的語言可以編譯下降至一個相應的“Intermediate Language”形式。
代碼在一“Intermediate Language”形式，可以輕鬆地結合起來，與其他代碼在一“Intermediate Language”形式。
一個計算機程序（也稱為“軟件” ） ，可以包括源代碼的書面在幾個不同的高層次的語言（例如， C# ， C++ ， Visual Basic ） 。
所有的源代碼可以編譯（改建）一“Intermediate Language”格式，讓容易結合起來，與其他編譯代碼。
計劃在1 “Intermediate Language”形式通常是轉換為機器具體的指示（例如， CPU指示）非常前不久，執行（例如， “Just-In-Time” (JIT)轉換IL ，以CPU指示） 。
但計劃也可能被處死，在一個Virtual Machine (VM)旨在解釋Intermediate Language (IL)指示。
編寫的代碼在各種高層次的語文( C#, F#, Ocaml, C++, Visual Basic, ... ) ，可編譯Intermediate Language (IL)形式使用適當的編譯器對任何支持的平台( Windows, Linux, MacOS X, ... ) ，和由此產生的文件，與嵌入式Intermediate Language (IL)代碼，是獨立於平台，並可以執行任何平台上有一執行該.NET Common Language Runtime (CLR) 。
該Intermediate Language (IL)代碼所產生的編譯器，基本上是獨立於哪一種平台上編譯被執行死刑。
1.3 Common Language Runtime (CLR)
該Common Language Runtime (CLR)是機制，負責執行的代碼提交上來，在Intermediate Language (IL)形式。
該Common Language Runtime (CLR)提供各種服務。
該Common Language Runtime (CLR)可轉換Intermediate Language (IL)代碼指示是本土向平台（例如， CPU指示） 。
轉換從Intermediate Language (IL)平台特定（例如， CPU具體）的指示，可能發生在任何提前執行（即，一“Ahead-Of-Time” (AOT)轉換） ，或可能出現的逐步，作為計劃執行（即， “Just-In-Time” (JIT)轉換） 。
該Just-In-Time (JIT)轉換可以使用不斷變化的統計程序執行動態優化轉換代碼（例如：確定經常使用的循環和分支，和優化他們根據觀察到的行為（即本身，取決於當前的數據和事件） ） 。
該Common Language Runtime (CLR)管理分配內存就代表該程序。
因此， CLR確保該計劃不會未能獲得分配內存，而參考這樣的記憶仍然存在，並確保內存分配的取消，以及記憶體提供了再次用於將來的分配後，計劃作主所有的提述，這種分配。
該Common Language Runtime (CLR)偵測時，該程序已不再提及內存分配，以及內存分配是標示為deallocation 。
該Common Language Runtime (CLR)使用任何一個不同的“垃圾收集”算法（例如： “mark-and-sweep” ） ，以確定和填海的內存塊不再進入一個程序。
該Common Language Runtime (CLR)處理程序例外。
該Common Language Runtime (CLR)執行安全政策。
該Common Language Runtime (CLR)使用“P/Invoke”機制，以負載平台的具體圖書館和引用（呼叫）功能，這些圖書館。
2. .NET ( FCL, IL, CLR )實現由Microsoft
2.1 導言
該.NET範式( FCL, IL, CLR )已實施了由Microsoft 。
最新的版本， “3.0” ，被釋放在2006.10 。
.NET 3.0組成的.NET 2.0 Framework Class Libraries和幾個新的圖書館，如“Windows Presentation Foundation” (WPF)與“Silverlight” （原WPF/E ，以前Sparkle ， ... ）的瀏覽器插件Firefox和Internet Explorer 。
Microsoft劃分.NET 2.0軟件在兩個不同的軟件包：
（ 1 ） .NET Framework Version 2.0 Redistributable Package
該可再發行組件包是所要求的最終用戶來執行程式建成為.NET範式。這個方案也必須安裝由發展商之前，必須先安裝和使用.NET Software Development Kit (SDK)下文提到的。
（ 2 ） .NET Framework Version 2.0 Software Development Kit
軟件開發工具包(SDK)是所需要的開發編譯C#源代碼Intermediate Language (IL)程式檔案。
這個套件包含各種開發工具和文件。
2.2 .NET Framework Version 2.0 Redistributable Package
該可再發行組件包是所要求的最終用戶來執行程式建成為.NET範式。
這個方案也必須安裝由發展商之前，必須先安裝和使用.NET Software Development Kit (SDK)下文提到的。
以下的網際網路網頁上，主要是.NET下載網頁：
一節名為“.NET Framework Version 2.0 Redistributable Package”有聯繫的三個硬件平台： “Download x86 version” ， “Download x64 version” ， “Download IA64 version” 。
舉例來說，下列連結“Download x86 version” ，導致1頁，題為“Microsoft .NET Framework Version 2.0 Redistributable Package (x86)”
（檔案名稱： dotnetfx.exe ;版本： RC1 ;發布日期： 3/22/2006 ;語言：簡體中文;下載大小： 22.4 MB ）
本地緩存的版本（只以供參考;潛在過時） ：
（檔案名稱已改為在這裡從原來的檔案名稱， “dotnetfx.exe” ，以避免混淆，它與1.1 Installer的版本也命名為“dotnetfx.exe” ） 。
2.3 .NET Framework Version 2.0 Software Development Kit (SDK)
軟件開發工具包(SDK)是所需要的開發編譯C#源代碼Intermediate Language (IL)程式檔案。
這個套件包含各種開發工具和文件。
以下的網際網路網頁上，主要是.NET下載網頁：
一節名為“.NET Framework Version 2.0 Software Development Kit”有聯繫的三個硬件平台： “Download x86 version” ， “Download x64 version” ， “Download IA64 version” 。
舉例來說，下列連結“Download x86 version” ，導致1頁，題為“.NET Framework 2.0 Software Development Kit (SDK) (x86)”
（檔案名稱： setup.exe ;版本： 2.0 ;發布日期： 11/7/2005 ;語言：簡體中文;下載大小： 354.0 MB ）
本地緩存的版本（只以供參考;潛在過時） ：
（檔案名稱已改為在這裡從原來的檔案名稱， “setup.exe” ，以避免混淆，它與所有其他安裝文件名為“setup.exe” ） 。
3. Microsoft Visual C# ： 1 Integrated Development Environment (IDE)計劃
3.1 導言
1 Integrated Development Environment (IDE)程序讓開發人員要編輯的源代碼和執行各種工具（例如：編譯器，調試器， … … ）的背景下一個單一的，統一計劃，充滿有用的視覺跡象顯示和控制。
“Microsoft Visual C# 2005 Express Edition”是一個無成本（沒有支付所需的） IDE可供下載從Microsoft 。
對於非數據庫的開發，這是幾乎是不可能的區分，這沒有成本的產品來自零售業，對口， “Microsoft Visual C# 2005” 。
我經常使用這兩種產品，專業和recreationally ，我還沒有看到任何實際的差異產品。
3.2 官方聯繫
互聯網網站的主要頁：
網頁關於“Visual C# Express Edition” ：
點擊“Download Now”上的按鈕頁的右側選擇下載選項。
（一種方法是推出一個安裝程序，將下載文件從Microsoft在每個安裝。
第二種方法是下載一個充分CD-ROM “ISO”的形象，這使得未來的離線安裝。
該ISO形象， “VCS.iso” （ 451,837,952字節; CRC 55884F2C ）對於32位元的x86英語，可能會被燒死的一CD-ROM使用“Nero 7 Ultra” ，例如。 ）
4. .NET ( FCL, IL, CLR )實施由Mono Project
4.1 導言
該.NET範式( FCL, IL, CLR )已實施了與會者在一組稱為該Mono Project 。
4.2 官方聯繫
項目選址：
軟件下載頁：
4.3 本地緩存版本
本地緩存版本的安裝程序（只以供參考;潛在過時） ：
4.4 .NET 2.0發展與Mono
該“mcs”編譯器，和文件，截至11月2006 ，大多涉及到C# 1.0和FCL 1.1 。
不過， “mcs”編譯器能夠編譯C# 2.0代碼不包含仿製或通用型功能，但限制API ，以1.0 。
這樣做充分C# 2.0發展，與FCL 2.0圖書館，使用“gmcs”編譯器。
請參閱下列網頁上Mono網站：
5. SharpDevelop ：開放源代碼Integrated Development Environment (IDE)計劃
5.1 導言
1 Integrated Development Environment (IDE)計劃允許開發人員要編輯的源代碼和執行各種工具（例如：編譯器，調試器， … … ）的背景下一個單一的，統一計劃，充滿有用的視覺跡象顯示和控制。
SharpDevelop是一個很好的，開放源代碼IDE計劃C# / .NET發展。
這IDE緊密合作，類似於Microsoft Visual C# IDE ，並在某些方面， SharpDevelop IDE有所改善後， Microsoft產品。
不過， Microsoft Visual C#有一些功能（例如：調試）表示， SharpDevelop程序沒有（在當時的這個寫作） 。
5.2 官方聯繫
簡單的互聯網網站主要頁：
網頁關於“The Open Source Development Environment for .NET” ：
下載網頁，其中有詳細介紹1.1和2.0版本的SharpDevelop ：
5.3 本地緩存版本
本地緩存版本的安裝程序（只以供參考;潛在過時） ：
6. 有用的C# / .NET / IL工具
6.1 SciTech Software “.NET Memory Profiler”
這Profiler中顯示內存分配，和其他的資源分配，即編譯.NET程序或大會，而使得執行。
實時圖形，使一個人看到，在詳細，如何行動的程序（如行動所引發的用戶輸入或其他事件）影響內存分配和垃圾收集。
實時時間表上市的看法，使一個人要了解詳情，內存分配。
這Profiler的即時，並大幅透露，浪費內存使用在一個真實的時間Direct3D計劃，我發展。
的格局，向上斜道和突然下降（由於“垃圾收集” ）在記憶體使用量的圖匹配完全與定期，極簡短的停頓，在三維圖形我的計劃。
的Profiler使我發現，頻繁的分配臨時對象是積累了大量的存儲空間，觸發垃圾收集頻繁，並採取足夠的時間，每個垃圾收集，造成數繪圖期不容錯過。
的Profiler的實時時間分配表的對象類型揭示了類型的對象，其中最消耗內存，並分配消耗內存在最高速率（每秒字節數） ，並分配了最高的處理率。
研究實時圖形和實時時間表，讓我把重點放在研究以何種方式的某些數據類型被用來在我的代碼。
修改代碼來避免頻繁的分配臨時對象可以大大減少的整體比率內存分配和處置，因此可以減少頻率垃圾收集觸發。
（我相信“Bytes/sec”是一個非常揭示了統計的實時時間內存使用中，除了“Live instances” 。
）看到所有這些正在更新很快，在一個表格式，並能夠選擇如何行分揀，和不斷變化的分揀參數在任何時間，使學習的經驗，一個真實的時間，程序非常具有吸引力和翔實。
內存分配的反應，用戶交互與正在運行的程序，可以研究，並測試能迅速適應的反饋意見，以縮小最有趣的方面。
（舉例來說， 2006 July版本有下列屬性：版本2.6.89 ; 4.3 MB ; USA $127.00 ;下載14天的限制版本，在沒有任何成本，進行評估。 ）
6.2 FxCop ： .NET代碼分析儀/影評
FxCop分析彙編.NET程式（或彙編大會） ，並生成一份報告，上市可能出現的問題，與原來的源代碼。
可能的性能問題和安全問題是確定的。
可能的編碼公約的行為確定。
FxCop並不需要訪問原始的源代碼來執行分析。
只有編譯.NET計劃（其中包含IL ）是必需的。
儘管如此， FxCop報告提供的超連結，以具體的行號在原來的源代碼。
如果Microsoft Visual C# 2005 IDE是積極的，點擊超連結，在FxCop報告將導致IDE ，以經向有關的源文件和行號。
FxCop已在我看來，一個頗為尷尬的方式結合Microsoft Visual C# 2005 IDE 。
不過，一旦它成立， FxCop產生了一個很有趣的和潛在的-有價值的報告。
該報告書載錄詳細的意見，就如何改進原有的源代碼。
我認為這是值得來分析一個程序使用FxCop就定期的基礎上。
我不會感到驚訝，如果有些軟件開發項目或企業所需的所有代碼的書面發展，收益率沒有警告或批評FxCop 。
規則可以添加或刪除從FxCop數據庫，根據需要。
FxCop是一個開放源代碼，免費程序。
6.3 “Reflector for .NET” ： decompiler /分析儀
從Lutz Roeder's互聯網站點：
"Reflector is the class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL."
“Reflector”可以幫助一個人研究如何第三黨的圖書館是書面。
有時將是非常有用的確切知道如何的一種方法在一個大會是落實。
如果一種方法表現在一個意想不到的或神秘的方式，然後“Reflector”可以用來見的執行情況。
所看到的執行情況，程序員可以工作，圍繞所引起的問題的具體實現圖書館的方法。
一個朋友告訴我， “Reflector”幫助他了解更多有關的行為不佳的記錄方法，在Microsoft執行該Framework Class Libraries (FCL) 。
“Reflector”可能會有所幫助時，文件一個圖書館的方法構成的，只有幾句話，如“集的價值”或“事件處理程序” 。
如果一個庫函數調用失敗，為一不明原因（當所有的參數，似乎有效） ，然後利用“Reflector”看看執行圖書館的功能，可能揭示了失敗的原因。
“Reflector”執行一些“逆向工程的”一個.NET程序或大會。
其他公用設施，其中可能包括“Reflector”本身，可以產生的源代碼程序或集會建成的基礎上模糊的源代碼。
這顯然是一個令人關切的一些開發商和投資者。
（ 2006 July ： Reflector.zip是版本4.2.45.0 ）
7. 因特網討論論壇
Google搜索是最好的方式，找到答案的具體問題對任何話題，但下面的網站多次出現在搜索結果中為C#和.NET問題。
網站下面是可怕，為探索許多冷靜的東西，人們所做的與C#和.NET 。
“The Code Project”網站擁有數以千計的令人感興趣和有用的文章，為C# ， C++ ，和其他語言及編程範式。
該“MSDN Code Gallery”網站有很多有趣的文章和代碼樣本相關Microsoft技術。
與其他因特網網站的相關C#和.NET ：
8. 一般註釋
8.1 平台獨立性
該Intermediate Language (IL)一樣， Java “字節碼” ，是平台獨立。
任何.NET兼容的編譯器會生成平台獨立Intermediate Language (IL)代碼形式的程序或集會。
程序打包為可執行文件（ “*.exe”檔案）必須有一些平台依賴性代碼具體到一個操作系統，以便得到適當的解釋，並展開為可執行軟件語境中的特定操作系統。
不過，本土的可執行部分的軟件文件，只是引用.NET CLR引擎，提交IL代碼包含在軟件文件的執行由CLR引擎。
Microsoft提供了一個實施該.NET水電費（編譯器， ...),和實施的Framework Class Library (FCL) ，只為Windows作業系統。
該Mono Project提供了實現的.NET水電費（編譯器， ...),和實現該Framework Class Library (FCL) ，用於以下操作系統： Windows ， Linux ， MacOS X ， BSD 。
8.2 速度相比，與non-CLR C / C++
該Common Language Runtime (CLR)方面.NET是的上下文中一C#程序執行。
該CLR執行“垃圾收集”和使程序能夠引用職能，在“非託管”圖書館（所有的圖書館沒有落實在Intermediate Language (IL) ） 。
任何功能是否多於純數學，純字符串操作，或純記憶體複製，將引用的職能，在“非託管”圖書館。
所有的文件操作，插座行動，制定行動，投入業務（鼠標，鍵盤） ，輸出業務（控制台） ，平台線程行動，精密計時器業務，窗口業務等，將引用的職能，在“非託管圖書館” 。
不幸的是，機制，引用“非託管”職能從CLR需要一個相當長的時間。
因此，整體的速度，程序執行，在上下文的CLR是noticably慢的程式，可引用“非託管”函數直接。
對於特定類型的軟件，速度也很重要。
對於特定類型的軟件，速度可以作出重要的差異，在主觀或心理的經驗，一個人使用該軟件。
對於特定類型的軟件，速度，可以使差異實現的目標和失敗的。
多線程，增加CPU速度，以及改善該CLR代碼發電設施，將有助於軟件執行語境中的該CLR執行速度更快。
不過，任何的程式碼執行外CLR ，並調用平台圖書館直接，難免會執行顯著快於軟件，執行與上下文的CLR 。
保證所提出的CLR ，以C#軟件，如安全彌合差距，託管代碼和非託管代碼，是在成本，這是不太可能減少。
因此，任何程序，這是非常密集的平台（例如：三維仿真或遊戲，文件處理器，網絡服務器等） ，可能是執行一個量級更快以外的CLR比時，執行內部CLR 。
不同的是巨大的。
此外，任何程序都執行了大量的低層次的操縱數據將執行明顯快以外CLR比內部CLR 。
程序執行語境中的該CLR執行不夠快是有益的許多實際用途。
作為CPU速度增加，並作為代碼更好地利用多個CPUs ，程序執行，在上下文的CLR將可用於更多的任務，需要高企的計算。
不過，在中2008該CLR仍是不適合3D遊戲的任何精密的，除非有非常積極的努力，作出的數目減少函數調用，以三維圖書館（ OpenGL或Direct3D ） ，可能是使用的概念，如“著色程式”和“顯示清單” ;有所減少的數目函數調用。
