是不是這個:ADO+ 引導資料種類的演變 (轉自 ms 一)

來源:互聯網
上載者:User
ado|資料 利用 .NET 架構簡化發布和解決 DLL Hell 問題
Steven Pratschner
Microsoft Corporation
2000年9月

摘要: 本文介紹彙編概念並說明 .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 表示全域彙編庫的視圖。



相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。