Microsoft Corporation
2001 年 7 月
摘要：本文包含有關 Microsoft .NET 和 Microsoft .NET 框架的常見問題。（共 15 頁打印頁）
內容
概念性問題
運行庫技術問題
術語
程序集
應用程序部署和隔離
垃圾回收
遠程處理
互操作性
安全性
概念性問題
運行庫技術問題
術語
程序集
應用程序部署和隔離
垃圾回收
遠程處理
互操作性
安全性
概念性問題
什么是 .NET 框架？
Microsoft .NET 框架是生成、部署和運行 Web 服務及應用程序的平臺。它提供了一個生產率高且基于標準的多語言環境，用于將現有投資與下一代應用程序和服務集成，同時提供了解決 Internet 規模應用程序的部署和操作難題的靈活性。.NET 框架由三個主要部分組成：公共語言運行庫、統一類庫的分層集合和稱為 ASP.NET 的 Active Server Pages 組件化版本。
返回到頂部
運行庫技術問題
術語
什么是公共語言運行庫 (CLR)？
公共語言運行庫是用于 .NET 框架應用程序的執行引擎。
它提供若干服務，包括：
- 代碼管理（加載和執行）
- 應用程序內存隔離
- 類型安全驗證
- IL 到本機代碼的轉換
- 對元數據（增強型類型信息）的訪問
- 托管對象內存的管理
- 代碼訪問安全性的強制
- 異常處理，包括語言間異常
- 托管代碼、COM 對象和預先存在的 DLL（非托管代碼和數據）間的相互操作
- 對象布局的自動化
- 對開發人員服務的支持（分析、調試等等）
返回到頂部
什么是通用類型系統 (CTS)？
通用類型系統是一個內置在公共語言運行庫中的豐富的類型系統，它支持大多數編程語言中存在的類型和操作。通用類型系統支持廣泛的編程語言的完整實現。
返回到頂部
什么是公共語言規范 (CLS)？
公共語言規范是一組構造和約束，它充當庫編寫器和編譯器編寫器的向導。它使庫完全可通過任何支持 CLS 的語言使用，并使那些語言可以相互集成。公共語言規范是通用類型系統的一個子集。對于正在編寫將由其他開發人員使用的代碼的應用程序開發人員，公共語言規范也非常重要。當開發人員按照 CLS 規則設計可公開訪問的 API 時，這些 API 很容易通過面向公共語言運行庫的所有其他編程語言使用。
返回到頂部
什么是 Microsoft 中間語言 (MSIL)？
MSIL 是與 CPU 無關的指令集，其中編譯進了 .NET 框架程序。它包含在對象上加載、存儲、初始化和調用方法的指令。
在與元數據及公共類型系統組合后，MSIL 允許真正的語言間集成。
在執行之前，MSIL 將轉換成機器碼，并且不被解釋。
返回到頂部
什么是托管代碼和托管數據？
托管代碼是為面向公共語言運行庫的服務編寫的代碼（請參閱“什么是公共語言運行庫？”）。為了面向這些服務，該代碼必須向運行庫提供最低級別的信息（元數據）。默認情況下，所有 C#、Visual Basic .NET 和 JScript .NET 代碼都受托管。默認情況下，Visual Studio .NET C++ 代碼不受托管，但編譯器可以通過指定命令行開關 (/CLR) 來產生托管代碼。
與托管代碼密切相關的是托管數據（由公共語言運行庫的垃圾回收器分配和釋放的數據）。默認情況下，C#、Visual Basic 和 JScript .NET 數據受托管。然而，通過使用特殊的關鍵字可以將 C# 數據標記為非托管。默認情況下，Visual Studio .NET C++ 數據不受托管（即使在使用 /CLR 開關時），但在使用 C++ 托管擴展時，可以通過使用 __gc 關鍵字將類標記為托管。正如名稱所暗示的，這意味著用于類實例的內存受垃圾回收器的托管。另外，類成為 .NET 框架社區的一名完全參與的成員，這既帶來了好處，也帶來了限制。其中一個好處是與用其他語言編寫的類的正確互操作性（例如，托管 C++ 類可以從 Visual Basic 類繼承）。其中一個限制是托管類只能從基類繼承。
返回到頂部
程序集
什么是程序集？
程序集是 .NET 框架應用程序的主要構造塊。它是一個功能集合，并以單個實現單元（一個或多個文件）的形式生成、版本化和部署。所有托管類型和資源或者只在其實現單元中標記為可訪問，或者在該單元外由代碼標記為可訪問。
程序集通過其清單（每個程序集不可缺少的部分）進行自我描述。清單可以：
- 建立程序集標識（以文本名稱的形式）、版本、區域性和數字簽名（如果程序集將在應用程序間共享）。
- 定義組成程序集實現的文件（按名稱和文件散列）。
- 指定組成程序集的類型和資源，包括從程序集導出的類型和資源。
- 逐條列出其他程序集上的編譯時依賴項。
- 指定程序集正確運行所需的權限集。
該信息在運行時用于解析引用、強制版本綁定策略和驗證加載程序集的完整性。運行庫可以確定和定位任何運行對象的程序集，因為每個類型均加載在程序集的上下文中。程序集也是應用代碼訪問安全權限的單元。在確定給程序集包含的代碼授予什么權限時，分別考慮每個程序集的標識證據。
程序集自我描述的特性也有助于使無影響安裝和 XCOPY 部署可行。
返回到頂部
什么是專用程序集和共享程序集？
專用程序集僅由單個應用程序使用，并存儲在該應用程序的安裝目錄中（或其中的子目錄中）。共享程序集是一個可以由多個應用程序引用的程序集。為了共享程序集，必須給予該程序集一個加密的強名稱（有時又稱強名稱），為此目的顯式生成程序集。相比之下，專用程序集名稱只需在使用它的應用程序中是唯一的。
通過區分專用程序集和共享程序集，我們以顯式決策的形式引入共享概念。只需將專用程序集部署到應用程序目錄，即可保證該應用程序只與用來生成和部署它的位一起運行。對專用程序集的引用只被本地解析到專用應用程序目錄。
可以舉出多個生成和使用共享程序集的理由，如表示版本策略的能力。共享程序集有一個加密的強名稱，這意味著只有此程序集的作者具有產生程序集新版本的密鑰。因此，如果您生成一個策略語句，表明自己希望接受程序集的新版本，則應確信版本更新將受作者的控制和驗證。否則，您不必接受它們。
對于本地安裝的應用程序，共享程序集通常被顯式安裝到全局程序集緩存中（由 .NET 框架維護的程序集的本地緩存）。.NET 框架版本管理功能的關鍵是：下載的代碼不影響本地安裝的應用程序的執行。下載的代碼放置在特殊的下載緩存中，并且在計算機上不是全局可用的，即使以共享程序集的形式生成了某些下載組件。
.NET 框架隨附的類均以共享程序集的形式生成。
返回到頂部
如果要生成共享程序集，需要簽名和管理密鑰對的系統開銷嗎？
生成共享程序集的確涉及使用加密密鑰。在生成程序集時，只有公鑰是確實需要的。面向 .NET 框架的編譯器在生成程序集時提供命令行選項（或使用自定義屬性）來提供公鑰。常見的做法是在源數據庫中保留通用公鑰的一個副本，并將生成腳本指向該密鑰。在交付程序集前，必須用相應的私鑰完全簽名程序集。用稱為 SN.exe（強名稱）的 SDK 工具來完成此工作。
與 Authenticode 不同，強名稱簽名不涉及證書。不涉及第三方單位，沒有要支付的費用，也沒有證書鏈。另外，驗證強名稱比驗證 Authenticode 的系統開銷低得多。然而，強名稱不就是否信任特定的發布者做出任何聲明。強名稱使您可以確保給定程序集的內容沒有被篡改，并且在運行時以您的名義加載的程序集來自您開發時所針對的同一發布者。但它不就是否可以信任此發布者的標識做出任何聲明。
返回到頂部
命名空間名稱和程序集名稱之間的差異是什么？
命名空間是類型的邏輯命名方案，此方案中簡單的類型名稱（如 MyType）用以點分隔的分層名稱開頭。這樣的命名方案完全受開發人員控制。例如，類型 MyCompany.FileAccess.A 和 MyCompany.FileAccess.B 可能在邏輯上應具有與文件訪問相關的功能。.NET 框架使用分層命名方案將類型分為相關功能（例如 ASP.NET 應用程序框架）或遠程處理功能的邏輯類別。設計工具可以利用命名空間使開發人員在代碼中瀏覽和引用類型更容易。命名空間的概念與程序集的概念無關。單個程序集可以包含分層名稱具有不同命名空間根的類型，而邏輯命名空間根可以跨越多個程序集。在 .NET 框架中，命名空間是邏輯設計時命名便利，而程序集在運行時建立類型的名稱范圍。
返回到頂部
應用程序部署和隔離
哪些選項可用于部署 .NET 應用程序？
.NET 框架通過使應用程序的無影響安裝和 XCOPY 部署切實可行來簡化部署。由于所有請求均首先解析到專用應用程序目錄，只需將應用程序的目錄文件復制到磁盤便可運行該應用程序。不需要任何注冊。
該方案對 Web 應用程序、Web 服務和獨立的桌面應用程序尤為迫切。然而，在某些情況下，XCOPY 作為分發機制是不充分的。應用程序只有很少的專用代碼并且依賴于共享程序集的可用性，或者應用程序不是在本地安裝的（而是按需下載的）便屬于這種情況。在上述情況下，.NET 框架提供大量的代碼下載服務以及與 Windows 安裝程序的集成。相對于當前平臺，.NET 框架提供的代碼下載支持提供了一些優點，包括增量下載、代碼訪問安全性（沒有其他 Authenticode 對話框）和應用程序隔離（代表一個應用程序下載的代碼不影響其他應用程序）。Windows 安裝程序是另一個可用于 .NET 應用程序的功能強大的部署機制。Windows 安裝程序的所有功能（包括發布、公布和應用程序修復）均適用于 Windows 安裝程序 2.0 中的 .NET 應用程序。
返回到頂部
我已經編寫了要在多個應用程序中使用的程序集。在哪里部署它？
將要由多個應用程序使用的程序集（如共享程序集）被部署到全局程序集緩存中。在預發布版和 Beta 版中，使用 GACUtil SDK 工具的 /i 選項將程序集安裝到緩存中：
gacutil /i myDll.dll
Windows Installer 2.0（隨附在 Windows XP 和 Visual Studio .NET 中）能夠將程序集安裝到全局程序集緩存。
返回到頂部
如何查看全局程序集緩存中安裝的程序集？
.NET 框架提供了一個用于查看程序集緩存的 Windows 外殼程序擴展。通過 Windows 資源管理器導航至 % windir%\assembly 將激活查看器。
返回到頂部
什么是應用程序域？
應用程序域（通常為 AppDomain）是一個用于隔離應用程序的虛擬進程。在同一應用程序范圍內（換句話說，以應用程序入口點開頭的對象激活序列中的任何位置）創建的所有對象都創建在同一應用程序域中。多個應用程序域可以存在于單個操作系統進程中，這使它們成為應用程序隔離的輕量方法。
操作系統進程通過提供一個獨特的內存地址空間來提供隔離。雖然這很有效，但成本很高，而且不能擴展到大型 Web 服務器所需的數目。另一方面，公共語言運行庫通過管理運行在應用程序域中的代碼的內存使用來強制應用程序隔離。這可確保它不會訪問域邊界以外的內存。注意只有類型安全代碼才能以這種方式進行管理（運行庫在不安全代碼加載到應用程序域中時無法保證隔離）很重要。
返回到頂部
垃圾回收
什么是垃圾回收？
垃圾回收是一種機制，它使計算機能夠檢測到對象何時不能再被訪問。然后它自動釋放該對象所使用的內存（同時調用由用戶編寫的稱為“終結程序”的清理例程）。有些垃圾回收器（如 .NET 使用的垃圾回收器）壓縮內存，從而減小程序的工作集。
返回到頂部
非確定性的垃圾回收如何影響代碼？
對于大多數程序員而言，擁有垃圾回收器（并使用垃圾回收對象）意味著即使使用復雜的數據結構，也不必擔心釋放內存或引用計數對象。但是，如果您通常在釋放對象內存的同一代碼塊中釋放系統資源（文件句柄、鎖等等），則確實需要在編碼樣式方面進行某些更改。對于垃圾回收對象，應提供一種以確定方式（即受程序的控制）釋放系統資源的方法，并使垃圾回收器可以在壓縮工作集時釋放內存。
返回到頂部
可以避免使用垃圾回收堆嗎？
所有面向運行庫的語言都允許從垃圾回收堆分配類對象。這帶來了快速分配方面的好處，并且使程序員不必計算出何時應顯式“釋放”每個對象。
CLR 還提供所謂的 ValueType。ValueType 與類相似，不同的是 ValueType 對象在運行時堆棧（而不是堆）上分配，因此當代碼退出定義了這些對象的過程時它們將被自動回收。這便是 C# 中“結構”的操作方式。
C++ 托管擴展使您可以選擇分配類對象的位置。如果由 __gc 關鍵字聲明為托管類，則它們從垃圾回收堆中分配。如果它們不包括 __gc 關鍵字，則它們的行為和常規 C++ 對象類似，都是從 C++ 堆分配，并且由“free”方法顯式釋放。
有關垃圾回收的附加信息，請參閱：
- 垃圾回收：Microsoft .NET 框架中的自動內存管理
- 垃圾回收（第 2 部分）：Microsoft .NET 框架中的自動內存管理
返回到頂部
遠程處理
進程內和進程間通訊在公共語言運行庫中的工作機制是什么？
進程內通訊有兩個方面：單個應用程序域中的上下文之間的通訊或應用程序域之間的通訊。在同一應用程序域的上下文之間，代理用作偵聽機制。不涉及任何封送處理或序列化操作。在跨越多個應用程序域時，我們使用運行時二進制協議進行封送處理/序列化。
進程間通訊使用可插接式信道和格式化程序協議，其中每個協議適用于特定的目的。
當在托管代碼和非托管代碼間進行轉換時，COM 結構（確切地說是 DCOM）用于遠程處理。在 CLR 的中間版本中，這通過適用于被服務的組件（使用 COM+ 服務的組件）。在最終發布時，應該可以配置任何可遠程處理的組件。
對象的分布式垃圾回收由稱為“基于租約的生存期”的系統托管。每個對象均有一個租用時間，當時間過期時，對象會與 CLR 的遠程處理結構斷開連接。對象都有默認的續訂時間，當從客戶端成功地調用了對象時續訂該租約。客戶端也可以顯式續訂租約。
返回到頂部
互操作性
可以在 .NET 框架程序中使用 COM 對象嗎？
可以。現已部署的任何 COM 組件均可通過托管代碼中使用，通常情況下，改編是完全自動的。
具體說來，自動行為是使用運行庫可調用的包裝 (RCW) 從 .NET 框架訪問 COM 組件。該包裝將 COM 組件公開的 COM 接口轉換成與 .NET 框架兼容的接口。對于 OLE 自動化接口，RCW 可以從類型庫中自動生成。而對于非 OLE 自動化接口，開發人員可以編寫自定義 RCW，并將 COM 接口公開的類型手動映射至與 .NET 框架兼容的類型。
返回到頂部
可以在 COM 程序中使用 .NET 框架組件嗎？
可以。現已生成的托管類型可通過 COM 訪問，通常情況下，配置是完全自動的。托管開發環境的某些新功能無法通過 COM 訪問。例如，靜態方法和參數化構造函數無法通過 COM 使用。通常情況下，最好提前確定給定類型的預期用戶。如果要通過 COM 使用類型，則可能只限于使用 COM 可訪問的功能。
根據用于編寫托管類型的語言，默認情況下，該類型可能是可見的，也可能是不可見的。
具體說來，自動行為是使用 COM 可調用的包裝 (CCW) 從 COM 訪問 .NET 框架組件。這與 RCW 類似（請參閱前一個問題），但工作方向相反。此外，如果 .NET 框架開發工具無法自動生成包裝，或者如果自動行為不是您所要的，則可以開發自定義 CCW。
返回到頂部
可以在 .NET 框架程序中使用 Win32 API 嗎？
可以。使用平臺調用，.NET 框架程序可以通過靜態 DLL 入口點訪問本機代碼庫。
下面是一個調用 Win32 MessageBox 函數的 C# 示例：
using System;
using System.Runtime.InteropServices;
class MainApp
{
[DllImport("user32.dll", EntryPoint="MessageBox")]
public static extern int MessageBox(int hWnd, String strMessage, String strCaption, uint uiType);
public static void Main()
{
MessageBox( 0, "Hello, this is PInvoke in operation!", ".NET", 0 );
}
}
返回到頂部
安全性
為使代碼適用于安全系統，必須做哪些工作？
這通常不是問題，大多數應用程序將安全運行，并且不會被惡意攻擊所利用。只需使用標準的類庫訪問資源（如文件）或執行受保護的操作（如類型的私有成員反射），安全性便由這些庫得到加強。開發人員可能需要做的一件簡單的事是包括權限請求（聲明安全性的形式），以限制代碼可以接收的權限（限制為它需要的權限）。這還可確保在允許代碼運行的情況下，只有具備了所需的所有權限才能這樣做。
只有編寫新基類庫公開新的資源類型的開發人員才需要直接使用安全系統。不是使所有的代碼都有潛在的安全危險，代碼訪問安全性將危險限制在顯式重寫安全系統的極少量代碼上。
返回到頂部
為什么在從網絡共享驅動器運行代碼時收到安全性異常？
默認的安全策略只向來自本地 Intranet 區域的代碼授予一組有限的權限。該區域由 Internet Explorer 安全設置定義，并且應配置為與企業中的本地網絡匹配。由于由 UNC 或映射驅動器命名（如用 NET USE 命令）的文件通過該本地網絡發送，這些文件也在本地 Intranet 區域中。
默認值是針對不安全 Intranet 的最壞情況設置的。如果您的 Intranet 比較安全，則可以修改安全策略（用 .NET 框架配置工具或 CASPol 工具），向本地 Intranet 或它的各部分（例如特定的計算機共享名稱）授予更多權限。
返回到頂部
如何使代碼在安全系統停止它時運行？
當代碼試圖執行無權執行的操作時會發生安全性異常。權限的授予基于已知的代碼情況，尤其是它的位置。例如，從 Internet 運行的代碼比從本地計算機運行的代碼獲得的權限少，因為經驗證明前者通常不如后者可靠。因此，為了使因安全性異常而失敗的代碼運行，必須增加授予它的權限。這樣做的一個簡單方法是將代碼移至更受信任的位置（如本地文件系統）。但這并不適用于所有情況（Web 應用程序便是一個很好的例子，公司網絡上的 Intranet 應用程序是另一個例子）。因此，如果不改變代碼的位置，還可以更改安全策略，向該位置授予更多權限。使用 .NET 框架配置工具或代碼訪問安全策略實用工具（caspol.exe）都可以做到這一點。如果您是代碼開發人員或發布者，則還可以為代碼加上數字簽名，然后修改安全策略，向帶該簽名的代碼授予更多權限。但是，在采用上述任何操作時，請記住給代碼授予的權限要少些，這是因為它不是來自可識別的可靠源。在將代碼移至本地計算機或更改安全策略前，應確保信任代碼不會執行惡意的或損害性操作。
返回到頂部
如何管理個人計算機的安全性？如何管理企業計算機的安全性？
.NET 框架包括 .NET 框架配置工具——MMC 管理單元（mscorcfg.msc）以配置包括安全策略在內的 CLR 的若干方面。該管理單元不僅支持在本地計算機上管理安全策略，而且還創建與系統管理服務器和組策略兼容的企業策略部署包。命令行實用工具 CASPol.exe 也可用于計算機上的腳本策略更改。為了在命令提示中運行任一種工具，請將當前目錄更改為 .NET 框架的安裝目錄（位于 %windir%\Microsoft.Net\Framework\v1.0.2914.16\）并鍵入 mscorcfg.msc 或 caspol.exe。
返回到頂部
基于證據的安全性如何與 Windows 2000 安全性一起使用？
基于證據的安全性（它授權代碼）與 Windows 2000 安全性（它基于登錄標識）一起使用。例如，為訪問文件，托管代碼必須既有代碼訪問安全性文件權限，還必須在具有 NTFS 文件訪問權的登錄標識下運行。.NET 框架中包含的托管庫還為基于角色的安全性提供了類。這些類使應用程序可以使用 Windows 登錄標識和用戶組。
返回到頂部