利用 .NET 框架簡化發布和解決 DLL Hell 問題
2024-07-10 13:00:00
供稿：網友
摘要： 本文介紹匯編概念并說明 .net 框架如何使用匯編解決版本和發布問題。
目錄
簡介
問題敘述
解決方案的特性
匯編：積木
版本與共享
版本策略
發布
摘要
--------------------------------------------------------------------------------
簡介
microsoft® .net 框架介紹了幾個新功能，旨在簡化應用程序發布和解決 dll hell。最終用戶和開發人員都熟悉版本和發布問題，這些問題會伴隨著如今基于組件的系統一同出現。例如，每個最終用戶都在他們的機器上安裝了一個新的應用程序，沒料到已有應用程序神秘地停止了工作。多數開發人員花費時間使用 regedit，努力保持所有必要的注冊項一致以便激活 com 類。
.net 框架中用于解決 dll hell 問題的設計原則和實現技術是建立在 microsoft windows® 2000 的基礎上的， rick anderson 所著的 the end of dll hell（英文）和 david d'souza, bj whalen 及 peter wilson 所著的 implementing side-by-side component sharing in applications (expanded) （英文）中都有說明。.net 框架提供的許多功能都在這兩篇文章中有所描述，包括應用程序隔離和并行組件，用于建立在 .net 平臺的應用程序。您將了解 .net 平臺上提供的版本支持，它能使本地 windows 應用程序更緊密地匯集。
本文介紹了匯編的概念，并描述 .net 如何使用匯編來解決版本和發布問題。我們將特別討論匯編如何構建，如何命名以及編譯器和通用語言運行時如何使用匯編來記錄和加強應用程序片段間的版本依賴。我們也將討論應用程序和管理員如何能通過我們所稱的版本策略定制版本行為。
介紹并說明了匯編后，將展示幾個發布方案，以便使您對 .net 框架中提供的各種打包和分發選項多少有一些了解。
--------------------------------------------------------------------------------
問題敘述
版本
從客戶的角度，最常見的版本問題就是我們所說的 dll hell 問題。簡單地講， dll hell 是指當多個應用程序試圖共享一個公用組件（如某個動態連接庫（dll）或某個組件對象模型（com）類）時所引發的一系列問題。最典型的情況是，某個應用程序將要安裝一個新版本的共享組件，而該組件與機器上的現有版本不向后兼容。雖然剛安裝的應用程序運行正常，但原來依賴前一版本共享組件的應用程序也許已無法再工作。在某些情況下，問題的起因更加難以預料。比如，當用戶瀏覽某些 web 站點時會同時下載某個 microsoft activex® 控件。如果下載該控件，它將替換機器上原有的任何版本的控件。如果機器上的某個應用程序恰好使用該控件，則很可能也會停止工作。
在許多情況下，用戶需要很長時間才會發現應用程序已停止工作。結果往往很難記起是何時的機器變化影響到了該應用程序。用戶可能會回憶起一周前安裝了一些東西，但安裝與目前看到的狀態并沒有任何明顯的關聯。 更糟的是，現在很少有診斷工具幫助用戶（或幫助他們的技術支持人員）確定有什么問題。
這些問題的原因是應用程序不同組件的版本信息沒有由系統記錄或加強。而且，系統為某個應用程序所做的改變會影響機器上的所有應用程序—現在建立完全從變化中隔離出來的應用程序并不容易。
很難建立一個隔離應用程序的一個原因是當前運行時環境只允許單獨版本組件或應用程序的安裝。這個限制意味著組件的編寫者必須以向后兼容的方式編寫他們的代碼，否則當他們安裝新組件的時候會有終止已有應用程序的風險。實際上，如果可能的話，編寫永遠向后兼容的代碼是非常難的。在 .net 中，side by side 概念是版本問題的核心。"side by side" 是在同一臺機器上同時運行不同版本的相同組件的能力。使用支持并列的組件，編程人員不必努力維護嚴格的向后兼容，因為不同的應用程序自由使用某個共享組件的不同版本。
發布和安裝
現在安裝應用程序是多步過程。一般，安裝一個應用程序包括復制許多軟件組件到磁盤，和在系統中進行一系列描述那些組件的注冊項。
注冊表中的項和磁盤上文件的分隔使復制應用程序和卸載他們非常困難。而且，在注冊表中完全描述某個 com 類所需的許多項之間關系非常松散。這些項常常包括聯合類、接口、類型庫和 dcom app id 的項，不涉及任何放在注冊表文檔擴展或組件類別的項。要時常手工保持這些項的同步。
最后，需要該注冊足跡激活任何 com 類。這極大地復雜了發布分布式應用程序的過程，因為必須到每個客戶端的機器進行適當的注冊項。
如今另一個共同問題是：對一個正在運行的應用程序進行更新是不現實的。這是 web 應用程序最大的問題，web 應用程序必須停止工作然后重啟動以更新應用程序使用的 com 類。
這些問題主要由從組件自己分離傳來的組件描述引起的。換句話說，應用程序不是自描述的和獨立的。
--------------------------------------------------------------------------------
解決方案的特性
.net 框架必須提供以下基本的能力解決剛剛描述的問題：
應用程序必須是自描述的：自描述的應用程序去掉了對注冊表的依賴，能夠毫無影響的安裝和簡單的卸載和復制。
必須記錄和加強版本信息：版本支持必須建立在平臺內部以保證依賴的適當版本在運行時載入。
必須記得“上次已知的正確配置”：當應用程序成功運行時，平臺必須提供記住這套一起工作的組件的能力—包括它們的版本—。
必須支持并列組件：允許多個版本的組件同時安裝和運行在機器上，允許調用者指定他們需要載入的版本代替不知不覺被強迫的版本。.net 框架通過允許框架自己的多個版本同時存在于一臺單獨的機器上使并列鄰先了一步。這極大地簡化了升級問題，因為管理員如果需要可以選擇運行不同版本 .net 框架上的不同應用程序。
必須使應用程序隔離： .net 框架必須簡化（實際上已經默認）編寫不受機器上其他應用程序的改變影響的應用程序。
--------------------------------------------------------------------------------
匯編：積木
匯編是 .net 框架用于解決剛描述的版本和發布問題的積木。匯編是類型和資源的發布單元。在許多方面匯編和現在的 dll 相同。從本質上講，匯編是“邏輯 dll”。
匯編是通過元數據調用清單自描述的。就像 .net 使用元數據描述類型一樣，它也使用元數據描述包含類型的匯編。
匯編不僅僅于發布有關。例如，.net 中的版本在匯編層完成 —沒有任何減少，就像一個模塊或類型的版本化。而且，匯編還用于在應用程序之間共享代碼。包含某個類型的匯編是該類型標志的一部分。
訪問安全系統的代碼在其許可模型的內核中使用匯編。匯編的編寫者在清單中記錄一組運行該代碼所需求的許可，然后管理員將許可授權給基于匯編的代碼，此匯編包含該代碼。
最后，匯編也是類型系統和運行時間系統的核心，在其中他們為類型和服務建立了一個可視的邊界作為解決引用類型的運行時間范圍。
匯編清單
清單明確包括以下有關匯編數據：
標識：一個匯編標識由三部分組成：名稱、版本號和選項文化。
文件列表：清單包括所有組成匯編的文件列表。對于每個文件，在建立清單時記錄它的名稱和內容的加密信息。該信息在運行時驗證以確保發布單元的一致。
引用的匯編：匯編間的關系保存在收集的匯編清單中。從屬信息包括版本號，它用于運行時保證載入正確版本的關系。
輸出類型和資源：對類型和資源可用的可視選項包括“僅在我的匯編中可視”和“對我的匯編之外的調用者可視。”
許可需求：匯編許可需求分為三組：匯編運行需求、需要的但匯編還有一些即使沒授權的功能的需求，以及編寫者不想匯編被授權的需求。
il 反匯編 (ildasm) sdk 工具對于在匯編中查看代碼和元數據很有幫助。圖 1 是一個以 ildasm 現實的范例清單。.assembly 表示匯編而 .assembly extern 包含有關其他匯編所依賴的信息。
圖 1. 以 il 反匯編顯示的范例清單
匯編結構
到此為止，匯編主要以邏輯概念描述。本節通過描述他們如何在物理上體現幫助您使匯編更加具體。
通常，匯編由四個元素組成：匯編元數據（清單）、元數據描述類型、實現該類型的媒介語言 (il) 代碼和一組資源。不是所有的這些都出現在每個匯編中。只有清單是嚴格需要的，但類型或資源需要給匯編一些重要的功能。
有幾個關于這四個元素能如何包裝的選項。例如，圖 2 表示包含整個匯編:清單、類型元數據、il 代碼和資源。
圖 2. 包含所有匯編元素的 dll
另一種情況，一個匯編的內容也許分割為多個文件。在圖 3 中，作者選擇將一些有用的代碼分離到一個不同的 dll 中，并在它的原始文件中保留一個大的資源文件（這里是一個 jpeg 文件）。這樣做的一個原因就是優化代碼的下載。.net 框架只在引用時才下載文件，所以如果匯編包含經常被訪問的代碼或資源，那么將他們分成單獨的文件將提高下載的效率。
圖 3. 匯編元素分割為多個文件
--------------------------------------------------------------------------------
版本與共享
dll hell 一個主要目的就是共享當前在基于組件的系統中使用的模型。默認情況下，單獨的軟件組件由機器上的多個應用程序共享。例如，每次一個安裝程序復制一個 dll 到系統目錄或在 com 注冊表中注冊一個類，該代碼將潛在地影響其他運行在機器上的應用程序。實際上，如果一個已存在的應用程序使用共享組件的前一個版本，那么該應用程序將自動使用新版本。如果共享組件是嚴格向后兼容的這當然更好，但如果不可能，在許多情況下維護向后兼容是很困難的。如果沒有維持向后兼容或不能維持，作為其他應用程序安裝時的側面影響經常導致應用程序中斷。
.net 設計方針的一個原則就是隔離組件（或匯編）。隔離一個匯編的意思是一個匯編只能由一個應用程序訪問—不是由機器上的多個應用程序共享并且不可能因其他應用程序對系統的改變而影響。隔離賦予開發者對應用程序所用代碼的絕對控制。隔離，或應用程序專用匯編期望在 .net 應用程序中是默認的。隔離組件的趨勢在 microsoft windows 2000 中隨著 .local 文件的引入已經開始。該文件用于努力定位所需組件時使 os loader 和 com 首先從應用程序目錄查找。（請參閱 msdn library 中的相關文檔，implementing side-by-side component sharing in applications（英文）。）
然而，有些情況下在應用程序之間共享匯編是必要的。很明顯每個應用程序都有自己的 system.winforms、system.asp 或公用的 web 表格控件的副本是沒有意義的。
在 .net 中，在應用程序之間共享代碼是明確的決定。共享匯編需要一些附加的需求。特別是，共享匯編應該支持相同的匯編并排多個版本安裝和運行在相同的機器上，或者甚至在相同的進程中，在相同的時間。另外，共享匯編有更嚴格的命名需要。例如，一個共享的匯編必須有一個全局唯一的名稱。
隔離和共享的需要導致我們考慮兩種匯編。這是個相當松散的集合，在這兩種匯編之間沒有實際的結構，但它們如何使用是不同的：專用于某個應用程序或與許多應用程序共享。
應用程序專用匯編
應用程序專用匯編是只對某個應用程序可視的匯編。我們期望這是 .net 應用程序最普通的情況，因為 .net 框架幫助建立從其它應用程序引起的系統變化中隔離的應用程序。
專用匯編的命名需求很簡單：匯編名稱必須在應用程序中是唯一的。沒必要起全局唯一的名稱。保持名稱唯一不是問題因為應用程序開發者完全控制哪個匯編與應用程序隔離。
應用程序專用匯編部署在使用它們的應用程序目錄結構中。專用匯編可以直接放在應用程序的目錄或它的子目錄中。通用語言運行時間通過稱為 probing 的進程查找這些匯編。"probing" 是匯編名稱到包含清單的文件名稱之間的簡單映射。
特別地，通用語言運行時間把匯編的名稱記錄在匯編引用中，追加“.dll” 并在應用程序的目錄中查找該文件。該方案中有一些變量，在那里運行時間會訪問匯編命名的子目錄中或匯編的風格命名的子目錄。例如，某個開發者會選擇將包含定位于德國的資源的匯編部署在稱為“de”的子目錄中，并將西班牙的資源部署在稱為“es”的子目錄中。
如前所述，每個匯編清單包括有關其關系的版本信息。該版本信息沒有為專用匯編而加強，因為開發人員完全控制了部署到應用程序目錄的匯編。
共享匯編
.net 框架還支持共享匯編的概念。共享匯編是在機器上由多個應用程序使用的。使用 .net，共享應用程序之間的代碼是明確的決定。共享匯編有些額外的需求用于解決現在我們經歷的共享問題。除了支持早先描述的并列之外，共享匯編還有許多嚴格的命名需求。例如，共享匯編必須有一個全局唯一的名稱。而且系統必須提供“名稱保護”—更確切的說,防止有人再使用編寫者的匯編名稱。例如，假設您是一個網格控件的廠家，并且發布了您的匯編版本 1。做為編寫您需要確信沒有其他人能發布聲稱為版本 2 的匯編或您的網格控件。.net 框架支持通過稱為共享名的技術支持支持這些命名需求。（在下一節詳細說明）。
通常，應用程序編寫者不對應用程序使用的共享匯編有同等程度的控制。結果，在每次引用共享匯編時都檢查版本信息。另外，.net 框架允許應用程序和管理員通過指定版本策略重載應用程序使用的共享匯編版本。
共享匯編通常部署到全局匯編庫。全局匯編庫是供多個應用程序使用的機器范圍的匯編庫。使用該庫不是必要條件，但這樣做有很多好處。例如，自動提供多個版本的匯編并行存儲。而且，管理員能使用該庫部署他們需要的每個機器上的應用程序要使用的缺陷修復或安全補丁。在該方案中，配置匯編到全局匯編存儲能影響機器上的多個應用程序。.net 框架利用版本政策（稍候描述）的概念解決了現在出現在系統中共享區域的問題，例如 %windir%/system32。
在庫中添加匯編需要明確的管理員操作—實際上，安裝過程必須有“管理員權限”。匯編從不在存儲結束作為運行一個應用程序的側面影響，也不是當前工作的共享匯編的任何存儲。在 visual studo .net 時間框架中，windows 安裝程序將更新為理解匯編和匯編庫。這意味著可以使用 windows 安裝程序的所有功能，例如使用 .net 應用程序選擇安裝和應用程序恢復。
.net sdk 包括兩個用于匯編庫的工具。第一個是稱為 al 的工具，它允許在庫中添加匯編。al 使開發和測試方案變得方便，它不需要創建整個 windows 安裝程序包在庫中添加一個匯編。使用 /install 開關在庫中添加匯編：
al /install:myassembly.dll
第二個工具是 windows shell extension，它允許您使用 windows explorer 操作庫。圖 4 表示全局匯編庫的視圖。
圖 4. 全局匯編庫
共享名
共享名用于使嚴格的命名需求與共享匯編結合起來。共享名有三個目標：
名稱唯一：共享匯編必須具有全局唯一的名稱。
防止名稱冒充：作為開發人員，不希望有人發布您的匯編的后繼版本并假稱它是您發布的，無論是意外還是故意的。
提供引用標識：當涉及引用一個匯編時，共享名用于保證載入的匯編來自所期望的發行者。
共享名使用公共密鑰加密實現。通常，過程如下所示：匯編的編寫者產生一對密鑰（或使用已有的），標記包含專有密鑰清單的文件，并給調用者提供公共密鑰。當引用匯編時，調用者記錄生成強名稱專有密鑰相應的公共密鑰。圖 5 略述了該過程在開發期間如何工作，包括密鑰如何存儲在元數據中及如何生成簽名。
該方案是稱為“main”的匯編，它引用一個稱為“mylib”的匯編。mylib 具有共享名。重要的步驟如下所述。
圖 5. 實現共享名的過程
開發者調用在密鑰對中傳遞的編譯器和一組匯編的源文件。密鑰對通常由稱為 sn 的 sdk 工具生成的。例如，下面的命令生成一個新的密鑰對并保存的文件中：
sn 杒 mykey.snk
多數的編譯器將匯編作為編輯步驟的一部分。下面是一個 c# 命令的例子，它接受密鑰對并給匯編簽名：
csc /t:library math.cs /a.keyfile:mykey.snk /a.version:1.0.0.0
當編譯器生成匯編時，公共密鑰作為匯編標識的一部分保存在清單中。包括公共密鑰作為標識的一部分給匯編提供了全局唯一的名稱。
匯編生成后，包含清單的文件由專有密鑰標記。結果簽名保存在文件中。
當編譯器生成 main 匯編時，mylib 匯編的公共密鑰就作為引用 mylib 的一部分保存在 main 的清單中。
在運行時，.net 框架中有兩個步驟保證共享名給予開發人員所需的利益。首先，在匯編安裝到全局匯編庫時，驗證 mylib 的共享名簽名。（沒有配置到庫中的驗證簽名的選項也是可用的。）驗證簽名保證 mylib 的內容從匯編建立以來沒有改變。第二步是驗證作為 main 引用 mylib 的一部分保存的公共密鑰與 mylib 身份的一部分的公共密鑰相匹配。如果這些密鑰相同，main 的作者就能保證載入的 mylib 版本來自同一個的發布者，該發布者編寫了建立 main 的 mylib 版本。當涉及 main 引用 mylib 時，該密鑰等效檢查在運行時完成。
術語“簽名”常常聯想到 microsoft authenticode。理解共享名和 authenticode 沒有任何關系是非常重要的。這兩個技術有不同的目標。實際上，authenticode 意味著對發行者信任的水平，而共享名不是。沒有與強名稱相關聯的授權許可或第三方簽名授權。另外，共享名簽名通常由編譯器本身作為編譯過程的一部分進行。但是，也有實用程序用于在 sdk 中簽名。
另一個值得考慮的是“測試簽名”工程。匯編的編寫者經常不能訪問需要完全簽名的專有密鑰。大多數公司很好的保護這些密鑰的存儲它只能被少數人訪問。結果，.net 框架提供少量在開發中的“測試簽名”技術，然后再“真實簽名”。
--------------------------------------------------------------------------------
版本策略
如剛剛所描述的，每個匯編清單記錄它創建所依賴的每個關系的版本信息。但是，有一些方案應用程序的編寫者或管理員需要在運行時以關系的不同版本運行。例如，管理員應該能發布故障排除版本而不需要重新編譯每個應用程序以便得到該修改。而且，管理員必須能列出因發現安全漏洞或服務故障從沒有使用的匯編的詳細版本。.net 框架通過版本策略在版本綁定中啟用了該靈活性。
匯編版本號
每個匯編都有四個部分組成的版本號作為它標識的一部分（就是說，一些匯編的版本 1.0.0.0 和 版本 2.1.0.2 是完全不同的與類裝載器有關的標識)。包括作為標識的一部分的版本主要用來區分用于并行目的的匯編的版本。
開發人員和管理員必須理解版本號的結構，因為它是通用語言運行時間如何加強匯編之間的版本關系的關鍵。
圖 6. 匯編版本號的四個部分
版本號的幾個部分是主要版本、次要版本、內部版本和修訂版本。主要版本或次要版本的改變可認為是不可兼容的改變。例如，開發人員改變了一些方法參數的類型或徹底刪除了一些類型。類裝載器使用該信息使所依賴匯編的不兼容版本不默認載入。
另一方面，僅改變版本號中的建立和版本部分可認為是兼容的。這些改變一般是故障排除或安全補丁，在這種情況下類型定義沒有在某種程度上中斷調用者的改變，這是兼容的。這些兼容的變化經常稱為 quick fix engineering (qfe) 修復或動態修復。
默認的版本策略
當通用語言運行時間遇到在代碼中引用匯編時，它決定載入所依賴匯編的版本。默認情況下，載入解決引用的匯編必須有與引用中的記錄相同的主版本號和次版本號。如果這些號碼不同，該匯編認為是不兼容的，并且不會默認載入。相反，通用語言運行時間會用最高的號碼得到 qfe (或動態修復)。
例如，如果 main 以 mylib 的 1.0.0.0 版本編譯，當運行發現 mylib 的 1.0.1.1 版本時，將載入 1.0.1.1。
總是取最新的編譯和版本的策略稱為“自動 qfe 策略”。該原則的主要目的是允許管理員在不重新創建所有應用程序的情況下發布故障排除版本。
定制版本策略
有些時候前面描述的默認策略并不是您所要的。例如，也許應用程序被所安裝的 qfe 不經意地中斷了。
默認的版本策略能通過使用 xml 配置文件修改。關于版本，有兩個文件：一個應用程序說明文件和一個機器范圍或管理員文件。應用程序說明文件保存在與應用程序相同的目錄中。該文件中的策略描述只影響該應用程序。機器范圍策略文件當前保存在 windows 目錄。該文件被管理員用來描述影響本機器上所有應用程序的策略。例如，也許某個管理員確定了某個匯編的詳細的版本具有一些安全漏洞，并且他確保該匯編將不再被使用。
自定義策略的示例包括：
綁定指定的版本
有時需要綁定一個與清單記錄的版本完全不同的匯編。通過在配置文件中的<bindingpolicy>標簽提供對該方案的支持。該策略用于映射某個關系指定版本的引用或某個關系所有版本的引用。
下面例子映射某個稱為 calcr 的匯編 6.0.0.0 版本的引用：
<bindingpolicy>
<bindingredir name="calcr"
originator="32ab4ba45e0a69a1"
version="*" versionnew="6.0.0.0"
uselatestbuildrevision="yes"/>
</bindingpolicy>
關閉自動 qfe 策略
該策略允許停止“自動 qfe 策略”引用已提供的匯編。 <bindingpolicy> 標簽也用在這里，但 uselatestbuildrevision 屬性設置為 no，如下面例子所示：
<bindingpolicy>
<bindingredir name="calcr"
originator="32ab4ba45e0a69a1"
version="*" versionnew="6.1.1212.14"
uselatestbuildrevision="no"/>
</bindingpolicy>
安全模式
安全模式（或編譯運行）策略用于恢復編譯配置。啟用該策略將使通用語言運行時間載入記錄在清單中的關系的一個精確版本。大概應用程序在它創建、測試并第一次發布時工作。安全模式是用于恢復到該狀態安全的網絡。下面的 xml 代碼為具體的應用程序打開安全模式：
<bindingmode>
<appbindingmode mode="safe"/>
</bindingmode>
如果某個具體的關系不符合版本規則或不經意引入一個錯誤，“安全模式”和“關閉自動 qfe 原則”可用于恢復應用程序到某個工作的狀態。
策略解決方案中的階段
本文已經介紹了幾個版本和發布的概念，包括應用程序專用匯編、共享的匯編、全局匯編存儲和用于指定版本策略的 xml 文件。本節通過描述通用語言運行時間查找匯編和應用版本策略經歷的階段將這些概念連接起來。
當通用語言運行時間遇到引用存儲在元數據中的另一個匯編時，開始載入匯編的過程。根據引用，下面的步驟決定載入那個匯編的哪個版本：
參考應用程序說明文件查看是否指定了策略。如果是，以策略的信息修改原始文件。例如，如果引用指定版本 1.0.0.0 而應用程序說明策略文件指定版本 2.0.0.0，通用語言運行時間將按照如同初始指定版本 2.0.0.0 一樣處理。
在應用程序目錄（和子目錄）中查找匹配的匯編?！捌ヅ洹倍x為精確的主版本號和次版本號（除非 qfe 策略被禁止）。
不管通過查找是否發現一個匹配項，全局匯編庫都將由 qfe 引用。這使管理員發布每個人都應該得到的故障排除。
最后，參考管理員策略文件。最后參考該文件是因為管理員最后決定載入哪個版本。
--------------------------------------------------------------------------------
發布
發布包含至少兩個不同的方面：包裝代碼和將這些包裝分布給運行該應用程序的客戶端和服務器。.net 框架主要的目標是通過毫無影響的安裝簡化發布和復制發布的可行性。匯編自描述的天性使我們擺脫對注冊表的依賴，因此使安裝、卸載和復制變得相當簡單。但是，有幾種場合下復制作為發布機制并不充分。在這些情況下，.net 框架提供擴展代碼下載服務并集成在 windows 安裝程序中。
包裝
在 .net 框架的第一個版本中有三個包裝選項可用：
as-built（dll 和 exe）。在許多場合，不需要特別的包裝。應用程序以發布工具制造的格式發布，即 dll 和 exe 的集合。
cab 文件。為了更有效地下載，cab 文件可用于壓縮應用程序。
windows 安裝程序包。 microsoft visual studio.net 和其他安裝工具允許建立 windows 安裝程序包（.msi 文件）。windows 安裝程序允許利用應用程序修復、選擇安裝以及其他 microsoft windows 2000 應用程序管理功能。
分布方案
.net 應用程序能以多種方式發布，包括復制、代碼下載以及通過 windows 安裝程序。
對于許多應用程序，包括 web 應用程序和 web 服務，發布和復制一組文件到磁盤并運行一樣簡單。卸載和復制就像刪除這些文件或復制它們一樣容易。
.net 框架提供使用 web 瀏覽器下載代碼的支持。該部分有幾個重要問題，包括：
零影響：沒有注冊表項添加到機器上。
增量下載：匯編的許多分塊只有在引用時才下載。
下載與應用程序隔離：代表某個應用程序的下載代碼不影響機器上其它的應用程序。支持代碼下載的主要目的是：防止用戶下載新版本的某個共享的組件影響瀏覽具體的 web 站點和影響其他應用程序。
no authenticode 對話框：訪問安全系統的代碼用于允許可移動代碼以部分信任程度運行。將不再出現對話框詢問用戶選擇是否信任該代碼。
最后，.net 完全集成到 windows 安裝程序和 windows 2000 應用程序管理功能中。
--------------------------------------------------------------------------------
摘要
.net 框架能夠零影響的安裝和訪問 dll hell。匯編是用于啟用這些功能的自描述、版本發布單元。
創建隔離應用程序的能力是緊要的，因為它使創建的應用程序不受其他應用程序對系統的改變所影響。.net 框架通過在應用程序的目錄結構中發布應用程序專用匯編，促進了這種應用程序。
并行是 .net 中共享和版本化問題的核心。并行允許某個匯編的多個版本同時在機器上安裝和運行，并允許每個應用程序請求那個匯編的指定版本。
通用語言運行時間記錄許多應用程序之間的版本信息，并在運行時使用該信息確保載入所依賴的適當版本。應用程序開發人員和管理員通過版本策略在選擇載入的匯編版本方面提供靈活性。
.net 提供幾個包裝和發布的選項，包括 windows 安裝程序、代碼下載和簡單復制。
本文來源于網頁設計愛好者web開發社區http://www.html.org.cn收集整理，歡迎訪問。
