Building,Packaging,Deploying,and Administering Applications and Types

標籤：

在我們進入章節之前，我們討論一下產生、打包和部署你的應用程式和應用程式類型必須的步驟。在這章裡，我將關注如何為你的應用程式的用途產生程式集。在第三章，“共用組件合和強命名程式集”，我將會涉及你需要瞭解的進階概念，包括如何產生和使用包含類型的程式集，這些程式集將被多個應用程式共用。在這兩章中，我也會討論管理員可以影響執行應用程式和它的類型的方式。

如今，應用程式由幾個類型組成，通常由你和微軟建立。此外，有很多組件供應商建立和出售類型，其它公司可以用來減少軟體項目開發時間。假如這些類型是用任何以CLR為目標的語言開發的，它們可以全部一起無縫的工作；一種語言寫的一個類型可以使用另一個類型做為它基類並且不關心基礎類型是用什麼語言開發的。

在這一章中，我將解釋這些類型為了部署怎麼產生和打包到檔案。在這個過程中，我將帶你回顧一些.NET Framework解決的問題。

.NET Framework Depoyment Goals（.NET Framework部署目標）

多年以來，Windows得到了一個不穩定和繁複的名聲。這個名聲是否名副其實要看很多不同的因素。首先，所有的應用程式使用微軟或其他供應商的動態連結程式庫（DLLs）。因為一個應用程式從各種各樣的供應商執行代碼，開發人員的任何一段代碼都不能100%的確定別人是怎麼使用它的。即使這種類型的互動存在各種各樣潛在的麻煩，事實上，這些問題一般不會出現因為應用程式在部署前都會進行測試和調試。

無論如何，當一家公司決定更新它的代碼和裝載新的檔案時使用者運行經常會遇到問題。這些新檔案被假設能向後相容之前的檔案，但是誰可以確定？事實上，當一家供運商更新它的代碼時，它一般發現它不可能重新測試和調試所有已裝載的應用程式以確保有不希望的影響。

我相信每個讀這本書的人都經曆過這個問題的變異：當安裝一個新的應用程式，你發現它以某種方式破壞了一個已經安裝好的應用程式。這種困境是眾所周知的“DLL地獄”。這種類型的不穩定在一般的電腦使用者心裡和大腦中都留下了恐懼的烙印。結果是使用者不得不小心考慮是否在他們的機器上安裝一個新的軟體。就我自己來說，我決定不嘗試安裝應用程式走出恐懼，它可能會對我依賴的應用程式產生不利的影響。

第二個原因，給前面提及的Windows名聲做出貢獻的是安裝的複雜性。如今，當安裝了大多數應用程式，它們影響系統所有的部分。例如，安裝一個應用程式引起檔案被拷貝到不同目錄，更新註冊表，在你的案頭和開始菜單/案頭安裝捷徑。這帶來的問題是應用程式沒有分離為一個單獨的實體。你不能容易的備份應用程式因為你必須拷貝應用程式的檔案和註冊的相關部分。此外，你不能容易的從一個機器行動裝置 App程式到另一個機器。你必須在運行一次安裝程式，所有檔案和註冊表才能設定正確。最終，你不能容易的卸載或者移除應用程式而沒有這種討厭的感覺，應用程式的一些部分還潛伏在你的機器上。

第三個原因和安全有關。當應用程式安裝好了，伴隨著它們的是各種各樣的檔案，其中很多是通過不同的公司寫的。此外，網頁應用程式經常有代碼（就像ActiveX控制項）這樣下載，使用者甚至沒有察覺代碼已經安裝在他們的機器上了。如今，這份代碼可以執行任何操作，包括刪除檔案或發郵件。使用者害怕安裝新的應用程式是正確的，因為它們會引起潛在的損害。為使使用者舒服，系統中必須建立安全，使用者可以明確地允許或者不允許不同的公司開發的代碼訪問他們的系統資源。

.NET Framework把DLL地獄問題放在重要位置，就像你將在這章和第三章裡看到的。.NET Framework在修複一個應用程式的狀態散布在使用者硬碟的各個角落問題走了很遠。例如，不像COM，類型不需要在在註冊表中設定。不幸的是，應用程式依然需要捷徑連結。至於安全，.NET Framework包含一個叫做代碼訪問安全（code access security）的安全模型。鑒於Windows安全是以使用者身份為基礎的，代碼訪問安全允許機主設定許可權，從而控制下載的組件可以做什麼。一個主應用程式像Microsoft SQL Server只給代碼少量授權，然而一個本地安裝（自我寄宿）的應用程式運行時擁有所有許可權。正如你將看到的，.NET Framework使使用者可以控制安裝什麼和運行什麼，總之，對於控制他們的機器，Windows從未這麼做過。

Building Types into a Module（類型產生一個模組）

在這個情境，我將給你看怎麼把你源檔案（包含不同的類型）轉換成一個可以部署的檔案。讓我們從仔細查看下面的簡單應用程式開始。

public sealed class Program    {        public static void Main(string[] args)        {            System.Console.WriteLine("Hi");        }    }

這個應用程式定義了一個類型，叫做Program。這個類型有一個單獨的公用的、靜態叫做Main的方法。在Main中應用了一個由微軟實現的叫做System.Console.System.Console的類型，並且在MSCorLib.dll檔案中實現了這個類型的方法的中繼語言（IL）代碼。所以我們的應用程式定義了一個類型同時也使用了另一個公司的類型。

產生這個簡單的應用程式，把之前的代碼放到一個原始碼檔案中，叫做，Program.cs，然後執行以下命令列：

csc.exe /out: Program.exe /t:exe /r:MSCorLib.dll Program.cs

這個命令列告訴C#編譯器發布一個叫做Program.exe（/out: Program.exe）的可執行檔。這個類型檔案產生一個Win32控制台應用程式（/t[arget]:exe）。

當C#編譯器處理源檔案，它看到代碼引用System.Console類型的WriteLine方法。這時候，編譯器要確定這個類型在哪裡存在，它有一個WriteLine方法，並且參數被傳遞給這個方法，且匹配方法期望的參數。因為這個類型不是在C#中定義的，為了使C#編譯器開心，你必須給它一個程式集使它能夠解決外部類型引用。在之前提到的命令列，我已經包括了/r[eference]:MSCoreLib.dll開關，它告訴編譯器通過MSCorLib.dll檔案定義的程式集尋找外部類型。

MSCorLib.dll是一個特殊的檔案，它包含所有的核心類型：Byte，Char，String，Int32和其他。事實上，這些類型是如此頻繁的被使用C#編譯器自動引用MSCorLib.dll程式集。換句話說，下面的命令列（省略/r 開關）和上面的命令列結果是一樣。

csc.exe /out: Program.exe /t:exe Program.cs

此外，因為/out: Program.exe和/t:exe命令列開關也匹配C#編譯器的預設選擇，下面的命令列也會給出相同的結果。

csc.exe Program.cs

假如，為了一些原因，你真的不想要C#編譯器引用MSCorLib.dll程式集，你可以使用/nostdlib開關。當建立MSCorLib.dll程式集時微軟使用這個開關。例如，當CSC.exe嘗試編譯Program.cs檔案時以下的命令列將會產生一個錯誤因為System.Console類型定義在MSCorLib.dll中。

csc.exe /out: Program.exe /t:exe /nostdlib Program.cs

現在，讓我們近一點看C#編譯器產生的Program.exe檔案。這個檔案實際上是什嗎？好吧，首先，它是一個標準的可移植執行體（portable executable,PE）檔案。這意味著一個運行32位或者64位版本Windows的機器可以載入這個檔案並用它做點什麼。Windows支援三種類型的應用程式。建立一個控制台使用者介面（console user interface,CUI）應用程式，指定/t:exe開關；建立一個圖形化使用者介面（graphical user interface,GUI）應用程式，指定/t:winexe開關；建立一個Windows商店App，指定/t:appcontainerexe開關。

Response Files（響應文檔）

在擱置關於編譯的開關的討論前，我要花一點時間談談響應文檔。一個回應檔是一個包含一個編譯器命令列開關集合的文字檔。當你執行CSC.exe，編譯器開啟響應文檔並使用詳細定義的開關就像命令列傳遞給CSC.exe的一樣。你命令編譯器通過在命令列前加@符號指定回應檔的名字使用指定的回應檔。例如，你有一個叫做MyProject.rsp的回應檔包含以下文本。

/out:MyProject.exe

/target:winexe

為了CSC.exe使用這些設定，你可以使用以下內容調用。

csc.exe @MyProjext.rsp CodeFile1.cs  CodeFile2.cs

這告訴C#編譯器輸出檔案時什麼名字和要建立什麼目標類型。就你看見的，響應文檔很方便因為你不需要每次編譯你的項目時手動給命令列參數表達你的意願。

C#編譯器支援多個響應文檔。除了文檔外你顯式指定在命令列的，編譯器自動在CSC.rsp文檔中尋找。當你運行CSC.exe，它尋找包含CSC.exe檔案的目錄以得到全面的CSC.rsp檔案。你需要應用到你的項目的設定應該都放在這個檔案中了。編譯器集合和使用在這些響應文檔中的設定。假如你在本地和全面響應文檔中有衝突設定，本地的設定重載在全面回應檔中的設定。同樣的，任何在命令列顯式傳遞的設定從本地回應檔重載設定。

Building,Packaging,Deploying,and Administering Applications and Types