名稱空間與程序集名稱之間有什么區(qū)別？
名稱空間是類型的一種邏輯命名方案，其中簡單類型名稱（如 MyType）前面帶有用點(diǎn)分隔的層次結(jié)構(gòu)名稱。這樣的命名方案完全在開發(fā)人員的控制之下。例如，鍵入 MyCompany.FileAccess.A 和 MyCompany.FileAccess.B 在邏輯上將會(huì)具有與文件訪問相關(guān)的功能。.NET 框架使用一種層次結(jié)構(gòu)命名方案，用于將類型按相關(guān)功能的邏輯類別進(jìn)行分組，例如，ASP.NET 應(yīng)用程序框架或遠(yuǎn)程處理功能。設(shè)計(jì)工具可以利用名稱空間使開發(fā)人員更容易在代碼中瀏覽和引用類型。名稱空間的概念與程序集的概念之間沒有任何聯(lián)系。一個(gè)程序集可以包含其層次結(jié)構(gòu)名稱具有不同名稱空間根的類型，而一個(gè)邏輯名稱空間根可以跨越多個(gè)程序集。在 .NET 框架中，名稱空間是在設(shè)計(jì)時(shí)進(jìn)行邏輯命名的便捷方式，而程序集在運(yùn)行時(shí)為類型建立名稱作用域。

應(yīng)用程序部署和隔離
部署 .NET 應(yīng)用程序時(shí)可以使用哪些選項(xiàng)？
通過使應(yīng)用程序的無影響安裝和 XCOPY 部署成為可能，.NET 框架簡化了部署。因?yàn)樗�有的�?qǐng)求首先在專用應(yīng)用程序目錄中進(jìn)行解析，所以只需簡單地將一個(gè)應(yīng)用程序的目錄文件復(fù)制到磁盤中，即可運(yùn)行該應(yīng)用程序，而不需要注冊(cè)。

此方案對(duì)于 Web 應(yīng)用程序、Web 服務(wù)和獨(dú)立的桌面應(yīng)用程序特別有吸引力。不過，在有些方案中 XCOPY 還不足以擔(dān)當(dāng)分發(fā)機(jī)制。例如，當(dāng)應(yīng)用程序具有很少的專用代碼，而依賴于可用的共享程序集；或者應(yīng)用程序不是安裝在本地（而是按需下載）。對(duì)于這些情況，.NET 框架提供了擴(kuò)展的代碼下載服務(wù)以及與 Windows Installer 的集成。.NET 框架提供的代碼下載支持通過當(dāng)前平臺(tái)提供了許多優(yōu)勢(shì)，包括增量下載、代碼訪問安全性（不再有“Authenticode”對(duì)話框）和應(yīng)用程序隔離（為一個(gè)應(yīng)用程序下載的代碼不會(huì)影響其他應(yīng)用程序）。Windows Installer 是 .NET 應(yīng)用程序可以使用的另外一個(gè)強(qiáng)大的部署機(jī)制。在 Windows Installer 1.5 中，Windows Installer 的所有特性（包括發(fā)行、公布和應(yīng)用程序修補(bǔ)）都可以在 .NET 應(yīng)用程序中使用。

如果我已經(jīng)編寫了一個(gè)程序集，并希望在多個(gè)應(yīng)用程序中使用它，我應(yīng)該在何處部署它？
要由多個(gè)應(yīng)用程序使用的程序集（如共享程序集）需要部署到全局程序集緩存中。在預(yù)發(fā)布版和 Beta 版中，使用 Alink SDK 工具的 /i 選項(xiàng)可將程序集安裝到緩存中：

al /i:myDll.dll
Windows Installer 的后續(xù)版本能夠?qū)⒊绦蚣�安裝到全局程序集緩存中。

如何才能看到在全局程序集緩存中安裝了哪些程序集？
.NET 框架附帶了一個(gè) Windows 外殼擴(kuò)展，用于查看程序集緩存。在 Windows 資源管理器中，轉(zhuǎn)至 % windir%\assembly 以激活查看器。

什么是應(yīng)用程序域？
應(yīng)用程序域（通常是 AppDomain）是用于隔離應(yīng)用程序的虛擬進(jìn)程。在同一個(gè)應(yīng)用程序作用域中創(chuàng)建的所有對(duì)象（換句話說，從該應(yīng)用程序的入口點(diǎn)開始沿著對(duì)象激活序列的任何地方）都在同一個(gè)應(yīng)用程序域中創(chuàng)建。多個(gè)應(yīng)用程序域可以存在于一個(gè)操作系統(tǒng)進(jìn)程中，使它們成為隔離應(yīng)用程序的簡便方式。

操作系統(tǒng)進(jìn)程通過使用各不相同的內(nèi)存地址空間來提供隔離。盡管它是有效的，但也是代價(jià)昂貴的，并且不能達(dá)到大型 Web 服務(wù)器所需要的數(shù)量。與其相比，公共語言運(yùn)行時(shí)通過管理在應(yīng)用程序域中運(yùn)行的代碼的內(nèi)存使用來強(qiáng)制進(jìn)行應(yīng)用程序隔離。這樣就確保它不會(huì)訪問應(yīng)用程序域以外的內(nèi)存。需要注意的是，只有類型安全的代碼才能以這種方式管理（當(dāng)在應(yīng)用程序域中加載不安全代碼時(shí)，運(yùn)行時(shí)不能保證隔離）。

垃圾回收
什么是垃圾回收？
垃圾回收是使計(jì)算機(jī)能檢測何時(shí)不再能夠訪問某個(gè)對(duì)象的一種機(jī)制。它將自動(dòng)釋放由該對(duì)象使用的內(nèi)存（也調(diào)用用戶編寫的稱為“結(jié)束者”的清理例程）。一些垃圾回收器（如由 .NET 使用的）會(huì)壓縮內(nèi)存，并因此減少程序的工作集。

非確定性垃圾回收是如何影響代碼的？
對(duì)于大多數(shù)編程人員而言，擁有一個(gè)垃圾回收器（并且使用可作為垃圾回收的對(duì)象）意味著永遠(yuǎn)不需要操心釋放內(nèi)存或引用計(jì)數(shù)對(duì)象，即使您使用了復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。但如果您通常在同一個(gè)用于釋放對(duì)象內(nèi)存的代碼塊中釋放系統(tǒng)資源（文件句柄、鎖定等等），那么在編碼樣式方面需要做一些修改。使用可作為垃圾回收的對(duì)象時(shí)，您應(yīng)該提供一種方法，來明確釋放系統(tǒng)資源（也就是說，由您的程序控制），同時(shí)允許垃圾回收器在壓縮工作集時(shí)釋放內(nèi)存。

是否能夠避免使用可作為垃圾回收的堆？
所有支持運(yùn)行時(shí)的語言都允許您從可作為垃圾回收的堆中分配類對(duì)象。這在快速分配方面帶來了好處，并且使編程人員無需自己來計(jì)算何時(shí)應(yīng)該顯式“free”每個(gè)對(duì)象。

CLR 還提供了 ValueTypes 對(duì)象——它們與類相似，但 ValueType 對(duì)象是在運(yùn)行時(shí)堆棧（不是堆）中分配的，因此當(dāng)您的代碼退出定義這些對(duì)象的過程時(shí)，將自動(dòng)回收它們。這就是 C# 中“struct”的操作方式。

C++ 的托管擴(kuò)展使您可以選擇類對(duì)象分配的位置。如果使用 __gc 關(guān)鍵字聲明為托管類，它們將從可作為垃圾回收的堆中分配；如果它們不包含 __gc 關(guān)鍵字，它們將與普通的 C++ 對(duì)象一樣從 C++ 堆中分配，并且使用“free”方法顯式釋放。

有關(guān)垃圾回收的的詳細(xì)信息，請(qǐng)參閱：

垃圾回收：Microsoft .NET 框架中的自動(dòng)內(nèi)存管理（英文）


垃圾回收 - 第 2 部分：Microsoft .NET 框架中的自動(dòng)內(nèi)存管理（英文）

遠(yuǎn)程處理
如何在公共語言運(yùn)行時(shí)中進(jìn)行進(jìn)程內(nèi)和進(jìn)程間通訊？
進(jìn)程內(nèi)通訊有兩種：在單一應(yīng)用程序域的上下文中，或者跨應(yīng)用程序域。在同一個(gè)應(yīng)用程序域的上下文中，使用代理作為監(jiān)聽機(jī)制，而不涉及封送處理/序列化。當(dāng)跨應(yīng)用程序域時(shí)，使用運(yùn)行時(shí)二進(jìn)制協(xié)議來作封送處理/序列化。

進(jìn)程間通訊為每個(gè)特定目的使用一個(gè)可插入通道和格式化程序協(xié)議。

如果開發(fā)人員使用 soapsuds.exe 工具指定終結(jié)點(diǎn)來生成元數(shù)據(jù)代理，那么默認(rèn)值是帶有 SOAP 格式化程序的 HTTP 通道。


如果開發(fā)人員在托管世界中執(zhí)行顯式遠(yuǎn)程處理，需要明確指定使用的通道和格式化程序。這可以通過配置文件用可管理的方式來表示，或者用 API 調(diào)用來加載特定通道。選項(xiàng)如下：
帶有 SOAP 格式化程序的 HTTP 通道（HTTP 在 Internet 上或任何必須通過防火墻進(jìn)行通信的時(shí)候運(yùn)行良好）

帶有二進(jìn)制格式化程序的 TCP 通道（對(duì)于局域網(wǎng)，TCP 是性能較高的選項(xiàng)）

帶有 SOAP 格式化程序的 SMTP 通道（僅對(duì)跨計(jì)算機(jī)有意義）

在托管代碼和非托管代碼之間進(jìn)行轉(zhuǎn)換時(shí)，COM 基礎(chǔ)結(jié)構(gòu)（尤其是 DCOM）用于遠(yuǎn)程處理。在 CLR 的中間版本中，這也適用于服務(wù)組件（使用 COM+ 服務(wù)的組件）。在最終版本中，配置任何遠(yuǎn)程組件都是可能的。

對(duì)象的分布式垃圾回收由名為“租用生存期”的系統(tǒng)來管理。每個(gè)對(duì)象都有一個(gè)租用時(shí)間，當(dāng)?shù)狡跁r(shí)，該對(duì)象與 CLR 的遠(yuǎn)程處理基礎(chǔ)結(jié)構(gòu)斷開連接。對(duì)象具有一個(gè)默認(rèn)的更新時(shí)間——當(dāng)客戶端成功地調(diào)用了對(duì)象時(shí)，租用將被更新�？蛻舳丝梢燥@式更新租用。

互操作性
是否可以在 .NET 框架程序中使用 COM 對(duì)象？
是。您現(xiàn)在部署的任何 COM 組件都可以在托管代碼中使用。通常情況下，所需的調(diào)整是完全自動(dòng)進(jìn)行的。

特別是，可以使用運(yùn)行時(shí)可調(diào)用包裝 (RCW) 從 .NET 框架訪問 COM 組件。此包裝將 COM 組件提供的 COM 接口轉(zhuǎn)換為與 .NET 框架兼容的接口。對(duì)于 OLE 自動(dòng)化接口，RCW 可以從類型庫中自動(dòng)生成；對(duì)于非 OLE 自動(dòng)化接口，開發(fā)人員可以編寫自定義 RCW，手動(dòng)將 COM 接口提供的類型映射為與 .NET 框架兼容的類型。

是否可以在 COM 程序中使用 .NET 框架組件？
是。您現(xiàn)在創(chuàng)建的托管類型都可以通過 COM 訪問。通常情況下，所需的配置是完全自動(dòng)進(jìn)行的。托管開發(fā)環(huán)境的某些新特性不能在 COM 中訪問。例如，不能在 COM 中使用靜態(tài)方法和參數(shù)化構(gòu)造函數(shù)。一般，提前確定給定類型所針對(duì)的用戶是一種較好的辦法。如果類型需要在 COM 中使用，您將被限制在使用 COM 可訪問的特性。

默認(rèn)情況下，托管類型可能是可見的，也可能是不可見的，這由用于編寫托管類型的語言決定。

特別是，可以使用 COM 可調(diào)用包裝 (CCW) 從 COM 訪問 .NET 框架組件。這與 RCW（請(qǐng)參閱上一個(gè)問題）相似，但它們的方向相反。同樣，如果 .NET 框架開發(fā)工具不能自動(dòng)生成包裝，或者如果自動(dòng)方式不是您所需要的，則可以開發(fā)自定義的 CCW。

是否可以在 .NET 框架程序中使用 Win32 API？
是。使用 P/Invoke，.NET 框架程序可以通過靜態(tài) DLL 入口點(diǎn)的方式來訪問本機(jī)代碼庫。

下面是 C# 調(diào)用 Win32 MessageBox 函數(shù)的示例：

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, "您好，這是 PInvoke！", ".NET", 0 );
    }
}

安全性
如何使代碼與安全系統(tǒng)協(xié)調(diào)工作？
通常，這不成問題——大多數(shù)應(yīng)用程序能安全地運(yùn)行，不會(huì)受惡意攻擊的干擾。通過簡單地使用標(biāo)準(zhǔn)類庫來訪問資源（如文件）或執(zhí)行受保護(hù)的操作（例如反轉(zhuǎn)類型的私有成員），安全性由這些庫來實(shí)施。應(yīng)用程序開發(fā)者需要完成的一項(xiàng)簡單工作是包括權(quán)限請(qǐng)求（一種公開的安全性），將代碼可能接收的權(quán)限限制在它所需要的權(quán)限范圍內(nèi)。這也確保了如果代碼被允許運(yùn)行，它在運(yùn)行時(shí)將具有所需的所有權(quán)限。

僅當(dāng)開發(fā)人員需要編寫提供新型資源的新基類庫時(shí)，他們才需要直接處理安全系統(tǒng)。在這種情況下，并非所有的代碼都有潛在的安全性問題，代碼訪問安全機(jī)制將其限制在替代了安全系統(tǒng)的那部分代碼上。

為什么在網(wǎng)絡(luò)共享驅(qū)動(dòng)器中運(yùn)行代碼時(shí)會(huì)發(fā)生安全異常？
默認(rèn)安全策略僅給來自本地 Intranet 區(qū)域的代碼授予有限的權(quán)限。這個(gè)區(qū)域是由 Internet Explorer 安全設(shè)置定義的，它們應(yīng)該配置為與企業(yè)內(nèi)部的本地網(wǎng)絡(luò)相匹配。由于由 UNC 或映射驅(qū)動(dòng)器（例如使用 NET USE 命令）命名的文件都需要在本地網(wǎng)絡(luò)上發(fā)送，因此它們也在本地 Intranet 區(qū)域中。

默認(rèn)值是為不安全的 Intranet 這種最壞情況而設(shè)置的。如果您的 Intranet 比較安全，您可以修改安全策略（用 CASPol 工具），給本地 Intranet 或其一部分（例如特定的計(jì)算機(jī)共享名）授予更多的權(quán)限。

如何編寫代碼，使它在安全系統(tǒng)停止該代碼時(shí)運(yùn)行？
當(dāng)代碼試圖執(zhí)行未經(jīng)授權(quán)的操作時(shí)，將發(fā)生安全異常。權(quán)限是基于代碼（尤其是其位置）來授予的。例如，從 Internet 中運(yùn)行的代碼所得到的權(quán)限比在本地計(jì)算機(jī)上運(yùn)行的代碼所得到的權(quán)限要少，這是因?yàn)榻?jīng)驗(yàn)證明，它的可靠性要低一些。因此，要運(yùn)行由于安全異常而失敗的代碼，您必須增加授予它的權(quán)限。一個(gè)簡單的方法是將代碼移到更受信任的位置（例如本地文件系統(tǒng)）。但這種方法并不是在任何情況下都有效（Web 應(yīng)用程序是一個(gè)很好的例子，企業(yè)網(wǎng)絡(luò)上的 Intranet 應(yīng)用程序是另一個(gè)例子）。因此，不要改變代碼位置，而是通過更改安全策略給該位置授予更多的權(quán)限。請(qǐng)使用代碼訪問安全策略工具 (caspol.exe) 或圖形化管理工具（在 Beta 2 和更高版本中可以得到）來執(zhí)行此操作。如果您是代碼的開發(fā)人員或發(fā)行者，您也可以對(duì)它進(jìn)行數(shù)字簽名，然后修改安全策略，給帶有該數(shù)字簽名的代碼授予更多權(quán)限。但是，在執(zhí)行上述任何操作時(shí)，請(qǐng)記住此代碼被授予較少的權(quán)限，是因?yàn)樗�不是來自受信任的來源——在將代碼移至本地計(jì)算機(jī)或更改安全策略以前，您應(yīng)該確保這些代碼不會(huì)執(zhí)行惡意或損壞性的操作。

如何管理個(gè)人或企業(yè)計(jì)算機(jī)的安全性？
目前，CASPol 命令行工具是管理安全性的唯一方法。安全策略由兩個(gè)級(jí)別組成：按計(jì)算機(jī)和按用戶。我們計(jì)劃在 .NET 框架第一版中提供全面的管理工具以及企業(yè)策略管理支持。

基于證據(jù)的安全性是如何與 Windows 2000 安全性配合工作的？
基于證據(jù)的安全性（基于授權(quán)碼）能與 Windows 2000 安全性（基于登錄身份標(biāo)識(shí)）配合工作。例如，要訪問一個(gè)文件，托管代碼必須具有代碼訪問安全文件權(quán)限，也必須在具有 NTFS 文件訪問權(quán)限的登錄身份標(biāo)識(shí)下運(yùn)行。.NET 框架中包括的托管庫也為基于角色的安全性提供了類。這些都使應(yīng)用程序能夠與 Windows 登錄身份標(biāo)識(shí)及用戶組配合工作。