Inside ASP.NET 2.0 佈署論典

動機：

自2005年底，.NET 邁入2.0架構後，我們發現越來越多的先進前輩，動身投入了 ASP.NET 2.0 的網路應用系統中；事實上不論您是否聽過我的研討會或是簡報吹噓，ASP.NET 2.0的確帶來了 ….. (超過兩萬字的最新功能形容… 省略)，但優越性能的背後，實際上也帶來了相對應的學習複雜度。

我特別喜歡一個長官的說法： 這是一個專業的問題，當然解決方式也是很專業的…

Cool… Right…

本文寫作的動機，在針對 ASP.NET 2.0 Compiler Model 與 VS.NET 2005 內建的佈署功能特性。希望在針對這個議題的討論，能讓Architect 或是已經Hands on 在開發的人員，得到一個 架構性的觀點，並且正確的使用工具來輔助您的軟體生活。

ASP.NET的On-Demand Compiler架構

圖表 1

微軟的 ASP.NET 架構，Build In 一個強大的 Compiler 模式，讓網頁在被瀏覽的時間，能夠快速 Compiler 為 組件DLL 被系統調用。這帶來了一個新的彈性架構，讓軟體開發端，不需要把所有的程式資訊事先 Compile 為密閉的DLL組件，甚至能動態的佈署單一網頁與更新。

但缺點呢?

在 1.x 版本，明顯的缺點在，系統在第一次被執行時會相對應的緩慢，因為所有的頁面都需要重新被掃描更新到對應的 DLL 組件中。

另一個更受抱怨的缺點在，一但有單一網頁被異動，系統需要重新早描異動變化，然後更新組件，這對於大型應用網站來說，是一種明顯的 Down Time… ， 金錢損失。

在 ASP.NET 2.0 的架構中，內定針對了這兩個通病做了大改進，Default 的ASP.NET 網頁架構，加入佈署的設計概念，同時也支援多重DLL對應的模式。要做到佈署，您有幾種選擇，一是透過Command Line 工具 “aspnet_compiler.exe”，一種是透過最佳化的IDE開發工具 Visual Studio 2005，後續的文章將以 VS 2005 為主要討論標地。

Visual Studio 2005 內建的ASP.NET佈署模式

VS 2005 內建提供了 Copy Web Site 與 Publish Wizard。Copy Web Site 是個Copy Source與Destination版本比對的工具，相單簡易使用，但不是本篇探討的主題，我們關心的是真正的佈署工具 Publish Wizard。

為了解釋起見，我選了 ASP.NET Starter Kits 的 “Club Web Site Starter Kit” 作為後續範例的樣本，您可以在 https://www.asp.net 中下載到它。

Starter Kits 的好處是，這已經是一個完整的案例，平常不用的時候，可以拿來做案例教學，設計學習，要用的時候又可以直接執行，安裝或是佈署，真的是 10 大開放源碼之一啊。 (星爺幽默)

前置作業.

請您準備一個新的 VS 2005 Web Sites，並且套用 Club Web Site Starter Kit 作為樣板；

在您的網站中，首先在根目錄中我們建立一個”ATestPage.aspx”，接下來在加入一個子目錄 “MyFolder”，並且在目錄內加入兩個簡單的 FooPage.aspx， 完成以後的專案架構如左圖：

接下來，在專案節點下案下滑鼠右鍵選擇 “Publish Web Site”, 我們討論的腳本由這裡開始：

Updateable 佈署模式

圖表 2

和ASP.NET1.x的內定腳本相同，ASP.NET 2.0 的執行引擎，允許您的.aspx網頁被即時監控與自動更新，要達到這個功能，VS 2005開發工具支援了Updateable 的佈署功能，讓您的ASP.NET 2.0應用程式，即使在正式上線的環境中，仍可直接改動單一網頁(.aspx/.ascx..)檔案，系統能夠自動更新。

為什麼採用 Club Web Site Starter Kit ?

微軟的Club Web Site Starter Kit前端的網頁全部都採用了 Code-Inline 方式撰寫，也就是網頁HTML敘述與對應的Event Handling 源碼，都放在同一個檔案中，這對我後續的說明有幫助。

我們可以觀察佈署以後的系統：

所有的 .aspx/ .ascx/ .master … 等 IIS 資源檔案全部會被佈署到環境中，同時所有的 .cs 檔案已經被 compiler 為對應的 .dll 組件檔，.aspx等頁面檔案，仍保持不變。在這個編程佈署的過程中，有個簡單的遊戲規則存在：

n App_Code 目錄的資料，完整的會被編程到單一的 App_Code.dll

n Global.asax 檔會被編程到 App_Global.asax.dll

n .aspx/.ascx /.master 的 code-behind 檔案，將會被按照目錄不同編程到不同的 App_Web_隨機碼.dll

直接打開 ILDASM 工具來驗證：

優缺?

Design 無對錯，只要最適合目前困境的設計就是個好的設計。Updateable的佈署架構，非常適合當系統佈署以後您的組織會需要頻率較高的調整網頁架構。然而 Updateable的佈署架構，因為仿照了過去 ASP.NET 1.x 架構，因此在系統頁面第一次被瀏覽時才會去編程對應的.aspx檔案，因此第一次都是會比較慢的呈現畫面。如果您的考量在不希望Page有Request Time Compiler的動作，那Updateable也許不是您的最佳佈署解。

Fixed Naming & Single Page 佈署模式

Fixed naming的佈署架構，在系統佈署之後，你會發現基本的檔案結構和 Updateable幾乎是一樣的，但肚子裡頭可是完全的不同了：

Fixed Naming 佈署模式基本上會將每一個IIS認得的資源單位獨立編程為單一的.DLL.，同時因為Page等事先會被編程，因此對應的 .ascx檔案根本上就不需要存在於佈署環境中；

一個遊戲規則依然存在：

n App_Code 目錄的資料，完整的會被編程到單一的 App_Code.dll

n Global.asax 檔會被編程到 App_Global.asax.dll

n .aspx/.ascx /.master 檔案與所屬的code-behind 檔案，將會被編程到各自獨立的 App_Web_隨機碼.dll

特點：

在 Fixed naming 的佈署模式下，您可以任意對某個頁面做版本更新，同時ASP.NET 2.0執行引擎不再監控每個 .aspx/.ascx/… 檔案，不會有 Request Time Compiler情境出現，使用者瀏覽網頁系統，完全不會有第一次瀏覽系統比較慢的情況出現。

混合Updateable & Fixed naming 佈署模式

瀏覽致此，您應該不難猜測何謂混合模式了吧 J

混合模式，簡單來說就是上述兩者佈署模式的特點做了整合，一但您的應用程式採用了這種佈署模式，您的系統將享有”單一.aspx/.ascx/.master的Code-Behind檔案” 單一.Dll的包裝，同時，您的.aspx/.ascx/.master頁面檔享有ASP.NET 2.0引擎監控更新的優勢；當然，因為即時間控下，Request Time Compiler會讓您的系統第一次瀏覽會比較慢。

我們同樣的做些簡單觀察：

還記得我們特地挑選的 Club Web Starter Kit 嘛，這裡剛好解釋了 我們自行加入的 FooPage等，因為採用了標準的 Code-Behind 架構，因此對應的 .cs 檔案已經被編程到 對應的.DLL組件中，但其他採用 Code-Inline架構編程的頁面，則交由ASP.NET 2.0 執行引擎監控與編程。

No Control with All Binary 佈署模式

如果您不打算對 Deployment 的組件做任何考量與思考的話，那麼將所有選項取消以後，您可以得到由VS 2005工具，針對您的站台頁面與設計的架構(相依性等考量)編程出來的純 .DLL 組件。在這個模式下，所有的 .aspx 等頁面檔案，一樣會和Fixed naming架構一樣，事先被 compiler 到 .DLL 組件內；您不能夠控制檔案對應的 .DLL 組件數目甚至名稱。

請注意，因為您不能控制組件名稱與數目，更新站台等於是要將所有 \bin\ 目錄中的 .dll 全部置換，否則系統會有組件 binding 等問題。

事實上，我應該說的更直接些，截至目前為止，我還想不出來任何一個觀點在實務上您會套用這種佈署模式 J，當然如果有，請您告知我也讓我成長些

另一個選項：Visual Studio 2005 Web Deployment Projects

緊接著在 05 年底上市的 VS 2005 工具，微軟在 06 年初附上了另一個佈署您 ASP.NET 專案的選項『Visual Studio 2005 Web Deployment Projects』，這是個 VS Add-In 工具，讓您在 ASP.NET 應用程式的佈署上，有更多的整合選擇方案。

VS 2005內建的佈署精靈，雖然是經過微軟內部緊密的針對開發人員腳本中，規劃出來的功能工具，然而對於真正的開發應用上，很快的就發現了內建功能在某些情敬上，並不足夠讓人滿足：舉例來說，在內建的佈署規劃中，開發人員無法為編程以後的組件命名；開發人員無法在編程佈署的過程中，針對”Pre-Build” / “Post-Build”做描述規劃，開發人員無法控制佈署後專案對應的IIS虛擬網站應用名稱。對80%的使用者來說，這也許並不重要，但對於20%的人員來說，這簡直是一種難以言喻的遺憾。

細膩的使用規範，在微軟的官方網站上可以取得

https://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx

圖文並茂的資訊，雖是以英文呈現，但是卻難不倒那些屬於20%的進階使用者。

對於Visual Studio 2005 Web Deployment Projects細節，小弟認為，因為已經有了詳細的英文說明，再加上前文中對於佈署架構的討論，對於同為軟體設計者的您而言，再次描述只是中文翻譯，浪費資源與汙辱您的智慧了。

結論

個人的學習經歷中，認為軟體架構師對於軟體成敗是覺對性的重要因素，但軟體架構師對於技術的細膩度卻不必然是100%掌控著，站在這個角度思維，我們就會發現，有些技術細節對於 軟體架構師 是十分重要的；因此 佈署的細節就不能馬忽地待過，這也是本文的重點：

提供您足夠的細節，讓您的決策與判斷力足夠清晰