名稱空間與程序集名稱之間有什麼區別？
名稱空間是類型的一種邏輯命名方案，其中簡單類型名稱（如 MyType）前面帶有用點分隔的層次結構名稱。這樣的命名方案完全在開發人員的控制之下。例如，鍵入 MyCompany.FileAccess.A 和 MyCompany.FileAccess.B 在邏輯上將會具有與文件訪問相關的功能。.NET 框架使用一種層次結構命名方案，用於將類型按相關功能的邏輯類別進行分組，例如，ASP.NET 應用程序框架或遠程處理功能。設計工具可以利用名稱空間使開發人員更容易在代碼中浏覽和引用類型。名稱空間的概念與程序集的概念之間沒有任何聯系。一個程序集可以包含其層次結構名稱具有不同名稱空間根的類型，而一個邏輯名稱空間根可以跨越多個程序集。在 .Net 框架中，名稱空間是在設計時進行邏輯命名的便捷方式，而程序集在運行時為類型建立名稱作用域。
應用程序部署和隔離
部署 .Net 應用程序時可以使用哪些選項？
通過使應用程序的無影響安裝和 XCOPY 部署成為可能，.Net 框架簡化了部署。因為所有的請求首先在專用應用程序目錄中進行解析，所以只需簡單地將一個應用程序的目錄文件復制到磁盤中，即可運行該應用程序，而不需要注冊。
此方案對於 Web 應用程序、Web 服務和獨立的桌面應用程序特別有吸引力。不過，在有些方案中 XCOPY 還不足以擔當分發機制。例如，當應用程序具有很少的專用代碼，而依賴於可用的共享程序集；或者應用程序不是安裝在本地（而是按需下載）。對於這些情況，.NET 框架提供了擴展的代碼下載服務以及與 Windows Installer 的集成。.NET 框架提供的代碼下載支持通過當前平台提供了許多優勢，包括增量下載、代碼訪問安全性（不再有“Authenticode”對話框）和應用程序隔離（為一個應用程序下載的代碼不會影響其他應用程序）。Windows Installer 是 .NET 應用程序可以使用的另外一個強大的部署機制。在 Windows Installer 1.5 中，Windows Installer 的所有特性（包括發行、公布和應用程序修補）都可以在 .Net 應用程序中使用。
如果我已經編寫了一個程序集，並希望在多個應用程序中使用它，我應該在何處部署它？
要由多個應用程序使用的程序集（如共享程序集）需要部署到全局程序集緩存中。在預發布版和 Beta 版中，使用 Alink SDK 工具的 /i 選項可將程序集安裝到緩存中：
al /i:myDll.dll
Windows Installer 的後續版本能夠將程序集安裝到全局程序集緩存中。
如何才能看到在全局程序集緩存中安裝了哪些程序集？
.Net 框架附帶了一個 Windows 外殼擴展，用於查看程序集緩存。在 Windows 資源管理器中，轉至 % windir%\assembly 以激活查看器。
什麼是應用程序域？
應用程序域（通常是 AppDomain）是用於隔離應用程序的虛擬進程。在同一個應用程序作用域中創建的所有對象（換句話說，從該應用程序的入口點開始沿著對象激活序列的任何地方）都在同一個應用程序域中創建。多個應用程序域可以存在於一個操作系統進程中，使它們成為隔離應用程序的簡便方式。
操作系統進程通過使用各不相同的內存地址空間來提供隔離。盡管它是有效的，但也是代價昂貴的，並且不能達到大型 Web 服務器所需要的數量。與其相比，公共語言運行時通過管理在應用程序域中運行的代碼的內存使用來強制進行應用程序隔離。這樣就確保它不會訪問應用程序域以外的內存。需要注意的是，只有類型安全的代碼才能以這種方式管理（當在應用程序域中加載不安全代碼時，運行時不能保證隔離）。
垃圾回收
什麼是垃圾回收？
垃圾回收是使計算機能檢測何時不再能夠訪問某個對象的一種機制。它將自動釋放由該對象使用的內存（也調用用戶編寫的稱為“結束者”的清理例程）。一些垃圾回收器（如由 .Net 使用的）會壓縮內存，並因此減少程序的工作集。
非確定性垃圾回收是如何影響代碼的？
對於大多數編程人員而言，擁有一個垃圾回收器（並且使用可作為垃圾回收的對象）意味著永遠不需要操心釋放內存或引用計數對象，即使您使用了復雜的數據結構。但如果您通常在同一個用於釋放對象內存的代碼塊中釋放系統資源（文件句柄、鎖定等等），那麼在編碼樣式方面需要做一些修改。使用可作為垃圾回收的對象時，您應該提供一種方法，來明確釋放系統資源（也就是說，由您的程序控制），同時允許垃圾回收器在壓縮工作集時釋放內存。
是否能夠避免使用可作為垃圾回收的堆？
所有支持運行時的語言都允許您從可作為垃圾回收的堆中分配類對象。這在快速分配方面帶來了好處，並且使編程人員無需自己來計算何時應該顯式“free”每個對象。
CLR 還提供了 ValueTypes 對象——它們與類相似，但 ValueType 對象是在運行時堆棧（不是堆）中分配的，因此當您的代碼退出定義這些對象的過程時，將自動回收它們。這就是 C# 中“struct”的操作方式。
C++ 的托管擴展使您可以選擇類對象分配的位置。如果使用 __gc 關鍵字聲明為托管類，它們將從可作為垃圾回收的堆中分配；如果它們不包含 __gc 關鍵字，它們將與普通的 C++ 對象一樣從 C++ 堆中分配，並且使用“free”方法顯式釋放。
有關垃圾回收的的詳細信息，請參閱：
垃圾回收：Microsoft .Net 框架中的自動內存管理（英文）
垃圾回收 - 第 2 部分：Microsoft .Net 框架中的自動內存管理（英文）
遠程處理
如何在公共語言運行時中進行進程內和進程間通訊？
進程內通訊有兩種：在單一應用程序域的上下文中，或者跨應用程序域。在同一個應用程序域的上下文中，使用代理作為監聽機制，而不涉及封送處理/序列化。當跨應用程序域時，使用運行時二進制協議來作封送處理/序列化。
進程間通訊為每個特定目的使用一個可插入通道和格式化程序協議。
如果開發人員使用 soapsuds.exe 工具指定終結點來生成元數據代理，那麼默認值是帶有 SOAP 格式化程序的 HTTP 通道。
如果開發人員在托管世界中執行顯式遠程處理，需要明確指定使用的通道和格式化程序。這可以通過配置文件用可管理的方式來表示，或者用 API 調用來加載特定通道。選項如下：
帶有 SOAP 格式化程序的 HTTP 通道（HTTP 在 Internet 上或任何必須通過防火牆進行通信的時候運行良好）
帶有二進制格式化程序的 TCP 通道（對於局域網，TCP 是性能較高的選項）
帶有 SOAP 格式化程序的 SMTP 通道（僅對跨計算機有意義）
在托管代碼和非托管代碼之間進行轉換時，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？
是。使用 P/Invoke，.Net 框架程序可以通過靜態 DLL 入口點的方式來訪問本機代碼庫。
下面是 C# 調用 Win32 MessageBox 函數的示例：
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 );
}
}
安全性
如何使代碼與安全系統協調工作？
通常，這不成問題——大多數應用程序能安全地運行，不會受惡意攻擊的干擾。通過簡單地使用標准類庫來訪問資源（如文件）或執行受保護的操作（例如反轉類型的私有成員），安全性由這些庫來實施。應用程序開發者需要完成的一項簡單工作是包括權限請求（一種公開的安全性），將代碼可能接收的權限限制在它所需要的權限范圍內。這也確保了如果代碼被允許運行，它在運行時將具有所需的所有權限。
僅當開發人員需要編寫提供新型資源的新基類庫時，他們才需要直接處理安全系統。在這種情況下，並非所有的代碼都有潛在的安全性問題，代碼訪問安全機制將其限制在替代了安全系統的那部分代碼上。
為什麼在網絡共享驅動器中運行代碼時會發生安全異常？
默認安全策略僅給來自本地 Intranet 區域的代碼授予有限的權限。這個區域是由 Internet Explorer 安全設置定義的，它們應該配置為與企業內部的本地網絡相匹配。由於由 UNC 或映射驅動器（例如使用 NET USE 命令）命名的文件都需要在本地網絡上發送，因此它們也在本地 Intranet 區域中。
默認值是為不安全的 Intranet 這種最壞情況而設置的。如果您的 Intranet 比較安全，您可以修改安全策略（用 CASPol 工具），給本地 Intranet 或其一部分（例如特定的計算機共享名）授予更多的權限。
如何編寫代碼，使它在安全系統停止該代碼時運行？
當代碼試圖執行未經授權的操作時，將發生安全異常。權限是基於代碼（尤其是其位置）來授予的。例如，從 Internet 中運行的代碼所得到的權限比在本地計算機上運行的代碼所得到的權限要少，這是因為經驗證明，它的可靠性要低一些。因此，要運行由於安全異常而失敗的代碼，您必須增加授予它的權限。一個簡單的方法是將代碼移到更受信任的位置（例如本地文件系統）。但這種方法並不是在任何情況下都有效（Web 應用程序是一個很好的例子，企業網絡上的 Intranet 應用程序是另一個例子）。因此，不要改變代碼位置，而是通過更改安全策略給該位置授予更多的權限。請使用代碼訪問安全策略工具 (cASPol.exe) 或圖形化管理工具（在 Beta 2 和更高版本中可以得到）來執行此操作。如果您是代碼的開發人員或發行者，您也可以對它進行數字簽名，然後修改安全策略，給帶有該數字簽名的代碼授予更多權限。但是，在執行上述任何操作時，請記住此代碼被授予較少的權限，是因為它不是來自受信任的來源——在將代碼移至本地計算機或更改安全策略以前，您應該確保這些代碼不會執行惡意或損壞性的操作。
如何管理個人或企業計算機的安全性？
目前，CASPol 命令行工具是管理安全性的唯一方法。安全策略由兩個級別組成：按計算機和按用戶。我們計劃在 .Net 框架第一版中提供全面的管理工具以及企業策略管理支持。
基於證據的安全性是如何與 Windows 2000 安全性配合工作的？
基於證據的安全性（基於授權碼）能與 Windows 2000
