.NET 部署指南(1)

導讀：
　　摘要
　　Microsoft .NET 框架提出了一種新的軟件開發規範，信息技術 (IT) 的從業者將會面臨一些風險，即在他們現有基礎結構上來管理和部署這些新的應用程序和組件。這份 .NET 部署指南爲部署基於 Microsoft .NET 框架的應用程序和組件提供了信息和指南。該指南提供了成功部署 .NET 應用程序的詳細描述，同時爲讀者提供了附加信息的鏈接
　　介紹
　　這份 .NET 部署指南的主要閱讀對象是 IT 經理、解決方案架構師，以及 IT 技術支持工程師，幫助他們部署爲 .NET 框架開發的應用程序和組件。除了提供部署過程的技術細節，這份指南還提供了體系結構指南和示例，幫助解決方案架構師和系統架構師有效地支持新的平臺。
　　這份指南並不提供關於 .NET 框架和 Visual Studio. NET 編程環境的全面信息。您可以從 .NET 框架 SDK 和 Microsoft Visual Studio .NET 的文檔以及 MSDN Library Web 站點上 http://msdn.microsoft.com/nhp/default.asp?contentid=28000519訪問這些信息。
　　.NET 框架概述
　　.NET 框架是一個新的開發平臺，它爲局域網 (LAN) 和 Internet 上的分佈式企業應用提供了一致和有效的支持。該平臺的關鍵特性包括：
　　統一的、語言無關的、面向對象開發環境，充分利用開發者已有的編程知識
　　無衝突軟件部署，避免組件的版本衝突
　　豐富的可執行模式，與存儲位置無關，組件可以在本地存儲執行，或者遠程存儲本地執行，或者在 Internet 上遠程存儲執行
　　安全代碼執行，具有高級安全設置以滿足現代組織的安全需求
　　 Windows 和 Web 應用程序具有統一的編程環境
　　通過在各自環境中高效的代碼編譯提升 Windows 和 Web 應用程序的執行性能
　　兼容的通信標準，確保 .NET 應用程序可以與其它應用程序和其它平臺的應用程序共存和集成
　　.NET 框架有兩大部分
　　公共語言運行時 (CLR)
　　 .NET 框架類庫
　　CLR 的作用是作爲運行和管理 .NET 代碼的代理。該代理負責一些基礎系統服務例如內存管理、線程管理、錯誤控制，以及類型安全。
　　開發者可以使用任何 .NET 兼容編程語言來編寫程序，而相應的編譯器會將它們都轉換成中間語言 (IL) 。CLR 使用高效的即時編譯 (JIT) 技術將語言無關的 IL 代碼轉換成特定設備的機器代碼。
　　託管代碼總是運行於編譯模式，併爲當前平臺做了優化；但是，代碼仍然受被託管以防止一般的執行錯誤。這種新的編程模型對於程序的運行提供了更加嚴格的控制，使得新的平臺對於分佈式應用程序來說更加健壯。
　　.NET 框架類庫是一個全面的面向對象的類型集合，您可以使用它來開發任何應用程序、服務或組件。該類庫取代了在 C++ 開發中普遍使用的 Microsoft 基礎類庫 (MFC) ，它被設計成易擴展的以便對其他服務提供面向對象的編程支持，這些服務例如 Microsoft Windows Server System 產品目前僅僅提供了專有的應用程序編程接口 (API) 。
　　.NET 框架開啓了在 Internet 上共享組件的大門。該技術使用了 Web 服務，因此不僅可供基於 Windows 的應用程序訪問，也可供運行於其它平臺上的應用程序使用，只要該應用程序使用了 Internet 標準如 TCP/IP 、 HTTP 、 XML ，以及 SOAP 。
　　用 .NET 框架開發的應用程序仍然可以使用 COM 組件，以充分利用以前開發的投資。但是，這種能力也帶來一些性能上的損失，因爲需要在兩種標準之間互相轉換。因此，將 COM 組件移植成 .NET 的託管代碼能夠極大地提升性能。
　　體系結構圖
　　圖 1 中的圖可以在 .NET 框架程序員指南中找到，該圖也是 MSDN (http://msdn.microsoft.com/library/en-us/cpguide/html/cpovrintroductiontonetframeworksdk.asp) 的一部分。
　　該圖顯示了三種不同的應用程序開發方案：
　　在 CLR 下運行託管代碼的程序
　　運行非託管機器代碼的程序
　　在 ASP.NET 下運行託管代碼的 Web 應用程序和 Web 服務
　　.NET 框架託管應用程序能夠與非託管應用程序共存於同一臺機器上。根據所選的編程語言，可以按需求編寫託管和非託管代碼。
　　

　　
　　圖 1：.NET 體系結構圖
　　
　　開發者可以用 .NET 框架設計很多不同類型的應用程序，例如：
　　 Windows 應用程序
　　類庫
　　 Windows 控件庫
　　 ASP.NET Web 應用程序
　　 ASP.NET Web 服務
　　 Web 控件庫
　　控制檯應用程序
　　 Windows 服務
　　安裝項目
　　 Web 安裝項目
　　 Visual Studio .NET 插件
　　這些應用程序需要不同的部署過程，本文重點介紹主要的可選方案。
　　.NET 程序集
　　爲了簡化應用程序和組件的部署，.NET 框架引入了程序集的概念。在 Windows Server 系統中，程序集是重用、版本控制、安全性、部署的單位。換句話說，程序集是一組任何類型的文件，它們必須一起部署。在某些情況下，程序集只是一個單獨的文件，例如一個 DLL 組件包或一個可執行程序。但是，程序集也可以包含其他文件，例如 HTML 頁面、 XML 文件，多媒體文件，或其它類型的文件。
　　開發者可以使用程序集將程序包需要部署的邏輯單元和需要部署的物理單元分離開來。這些程序集可以是一個應用程序的一部分並和它一起部署，也可以是由多個應用程序使用的共享程序集。
　　程序集信息存儲在清單中，每個程序集都自動包含清單。Visual Studio .NET 集成開發環境生成方案自動將清單插入 .EXE 或 .DLL 文件中，可以使用 ildasm.exe 工具（.NET 框架 SDK 的一部分）來觀測程序集清單，如下例所示（一個簡單的 HelloWorld VB.NET 應用程序）。
　　

　　
　　圖 2：用 ildasm.exe 反彙編程序集的清單
　　.NET 的 XCOPY 部署
　　.NET 程序集的部署與以前版本相比顯得簡單的多，可以被稱爲 XCOPY 部署。XCOPY 部署意味着在很多情況下，都只用簡單地將 .NET 應用程序目錄拷貝到目標位置。
　　以下的 .NET 特性使得該簡單部署過程成爲可能。
　　每個程序集都是自描述的，因爲程序集包含定義其內容的元數據。這個特性杜絕了用無止境的註冊表登記項來定義各個組件的公共接口的做法。
　　 .NET 程序集中的每個組件都使用標準的位置，因此不需要在註冊表中進行定義。
　　可以用配置文件來修改組件的位置，不過程序集在標準位置查詢這些配置文件，從而避免了註冊過程。
　　但是，還有部署過程更加複雜的情形，例如：
　　 .NET 應用程序與 COM 組件的交互仍然需要註冊。
　　在遠程計算機上將程序集預編譯爲本地代碼需要比僅僅將文件拷貝到目標目錄更多的過程。
　　將程序集安裝到遠程計算機的全局程序集緩衝中時需要更多的步驟以使該程序集成爲全局共享程序集。
　　當安裝與 .NET 框架一起部署的 Windows 服務時，這些服務需要在目標系統註冊。
　　某些 .NET 應用程序安裝過程需要在其它服務中設置對象，如活動目錄、 Internet 信息服務，以及集成於 Windows Server 系統的服務器軟件，需要運行其他的應用程序或腳本來創建和配置這些對象。
　　當定製一個用戶環境，例如開始菜單項、桌面快捷方式、控制面板小程序、自定義文件夾以及 Office 外接程序時，需要安裝程序創建所有這些自定義的項目。
　　用 Windows 安裝程序部署 .NET
　　Windows 安裝程序爲所有類型的應用程序和組件的部署提供了統一的解決方案。部署通過 Windows 安裝程序文件完成， Windows 安裝程序文件具有 .msi 擴展名，它包含了對應用程序安裝的描述，包括：
　　所有的應用程序文件，以壓縮模式出現
　　安裝過程中所有可選的選項，包括圖形用戶界面安裝過程或無人自動完成過程
　　應用程序文件的位置
　　用戶環境設置，例如開始菜單項和桌面快捷方式和圖標
　　卸載信息
　　註冊需求（需要時）
　　成功安裝和註冊應用程序的其它必需設置
　　部署 .NET 應用程序需要 Windows 安裝程序 2.0 或更高版本， Windows 2000、Windows XP、以及 Windows Server 2003 的所有版本都提供該安裝程序。獲取其它平臺上 Windows 安裝程序的更新版本的詳細步驟將在本文後面敘述。
　　要創建 .msi 文件，需要使用第三方工具。獨立軟件供應商，如 Installshield Software Corporation (www.installshield.com) 和 Wise Solutions, Inc. (www.wise.com) ，提供了不同的產品來製作 .msi 包。也可以用 Microsoft Visual Studio .NET 來替換這些工具，這些將在本文後面敘述。
　　MSI 數據庫實用工具
　　Windows 安裝程序 SDK （包含在 Windows 平臺 SDK 中）允許用 ORCA.EXE 工具查看和編輯已有的 .msi 包。該 SDK 可以從 http://www.microsoft.com/msdownload/platformsdk/sdkupdate/處下載。
　　該 SDK 包括 msidb.exe 工具，可以用它來導入和導出數據庫表和流，合併 .msi 數據庫，進行 Windows 安裝程序數據庫的轉換。要了解更多關於 ORCA 和 MSIDB 工具的信息，請參考 Windows 安裝程序 SDK 文檔。
　　用 Microsoft Application Center 部屬 .NET
　　Application Center 2000 提供了在負載平衡 Web farm 或故障轉移羣集服務器上部署 .NET 應用程序的工具。羣集中的所有服務器在 Application Center 2000 中作爲一個單獨的服務器來管理。羣集之間的同步保證了應用程序映像在所有成員服務器上被自動複製。
　　不用關閉任何服務就可以更新服務器應用程序，這樣提高了可用性。Application Center 2000 簡化了從開發工作站部署新的應用程序或新的版本以及部署失敗時進行的回滾。也可以通過 Application Center 2000 使用腳本語言來使部署過程自動化，這依賴於它功能全面的 API 。
　　關於 Application Center 2000 詳細功能的信息超出了本文的範圍。要獲取該產品的額外信息，請訪問 http://www.microsoft.com/applicationcenter/.
　　用 Microsoft System Management Server 部署 .NET
　　Microsoft System Management Server (SMS) 可以爲 Windows 安裝程序包提供附加的功能，特別針對的情況是向客戶端計算機分發 Windows Server 2003 以及向多個 .NET Web 服務器分發 ASP.NET 和 Web服務。
　　使用 SMS ，可以獲得額外的特性和配置優勢，例如：
　　向基於預定義管理規則的目標用戶和計算機智能化分發軟件
　　預先進行目標系統硬、軟件需求檢查
　　高級軟件統計以跟蹤軟件的使用，以幫助設計合適的基礎結構來處理實際和預測中的工作負荷。
　　高級疑難解答工具以精細調整系統和網絡基礎結構
　　要使用 SMS 2.0 部署 Windows 安裝程序安裝包，,需要執行下列任務：
　　在目標計算機上驗證 Windows 安裝程序運行時的可用性
　　使用 Windows 安裝程序的管理安裝來設置一個源包的路徑。
　　創建一個包。
　　配置彈性資源（可選）。
　　使用 Windows 安裝程序命令行語法爲包創建一個程序。
　　爲包指定分發點。
　　爲包指定訪問賬戶（可選）。
　　創建一個公佈
　　要獲取更多關於使用 SMS 部署 Windows 安裝程序安裝包的信息，請參閱“使用 System Management Server 2.0 部屬 Windows 安裝程序安裝包”，見 (http://www.microsoft.com/smserver/techinfo/deployment/20/deployosapps/deploymsi.asp) 。
　　但是，建議使用 Microsoft Application Center 在羣集或 Web farm 中部署 Web 服務和 ASP.NET 應用程序。
　　創建一個部署項目規劃
　　項目規劃是部署 .NET 應用程序的邏輯過程中一個重要的步驟。設計項目規劃是爲了滿足商業基礎結構和需求。Microsoft 操作框架 (MOF) 提供了部署過程指南。要獲取關於 MOF 的額外信息，請訪問 MOF Web 站點 www.microsoft.com/mof 。
　　生成一個項目規劃時需要考慮的步驟是：
　　創建一個項目規劃大綱：
　　定義項目範圍和目的
　　確定適當的部署進度表
　　按照常規 MOF 指南的定義規劃部署
　　確定資源/人員需求
　　建立項目團隊
　　收集當前環境信息
　　建立標準和指導方案
　　風險管理
　　培訓
　　測試和試驗概述
　　確定技術參考和依賴
　　完成項目規劃
　　部署 .NET 解決方案的過程通常是一個重複的任務，因爲一個新的 .NET 解決方案的部署與上一個解決方案並沒有很大的區別。但是，雖然大多數解決方案都會遵循一個十分相似的過程，遵循一個適當的部署規劃可以確保用最小的風險來成功地進行部署。
　　部署管理結構應該與目前的管理結構緊密結合，但是管理結構應該適合管理下列階段：
　　規劃 .NET 解決方案的部署
　　設計和管理一個 .NET 實驗室來測試 .NET 解決方案的部署
　　完成最終在產品環境中的部署
　　開發項目規劃過程
　　.NET 解決方案的部署遵循一個生命週期，從目的和目標的定義到最後在產品環境中的部署。規劃一個部署項目的過程中應該提供一個供遵循的合理指導方案，該指導方案詳細描述了怎樣進行設計、實現、測試、修改，以及執行每個動作。
　　確定目的和目標
　　在規劃過程的這個階段，需要確定將要部署的 .NET 解決方案的主要邏輯配置並特別強調安全性和功能可用性。網絡基礎結構在該階段扮演至關重要的角色，因爲網絡基礎結構被設計爲業務的安全性和功能性提供服務。
　　該階段的目的是定義部署項目的框架，以確保在部署過程中獲取必需的執行批准。這第一階段應該回答與特定部署項目相關的問題，例如：
　　爲什麼您的組織要部署這個特定的 .NET 解決方案？
　　該解決方案何時能夠啓用？
　　該項目的具體範圍？
　　該項目會影響到誰？
　　怎樣纔算是成功的部署？
　　系統中是否已經實現了其它 .NET 解決方案？如果是，它們與該項目中將要部屬的解決方案之間是否會發生潛在的交互？
　　有沒有其它應用程、系統或軟件會受到該解決方案部署的影響？如果是，是否需要將它們集成到新的解決方案中？怎樣進行集成？
　　有什麼樣的風險？
　　整個過程將包括哪些人？
　　在這個階段可能創建的文檔包括：
　　目的和目標文檔
　　當前環境概述
　　風險評估
　　該階段對於確定部署的里程碑非常重要。您需要向所有參加的團隊提供一個清晰的概念如爲什麼要部署該解決方案、它會怎樣影響目前環境、以及將怎樣進行部署。
　　邏輯項目大綱：策略問題
　　一個典型的 .NET 解決方案包含一些不同的實體
　　後端服務器
　　應用程序服務器
　　 Web 服務器
　　終端用戶應用程序
　　用戶
　　圖 3 顯示了一個 .NET 解決方案典型的網絡拓撲結構。
　　

　　
　　圖 3 ：一個典型的 .NET 解決方案
　　
　　用戶可以是內部或外部用戶，對於兩者來說，確定他們可以訪問該解決方案的哪些功能是非常重要的。內部用戶應該按照他們與該解決方案相關聯的訪問級別來分組。而對外部用戶來說，情況就稍稍複雜一些，因爲必須區分客戶、供應商以及合作伙伴，甚至從外部網絡連接進來的員工。定義對於每個組哪些可用哪些不可用需要細心的規劃。
　　在很多情況下，終端用戶應用程序會是 Web 服務器上基於 ASP.NET 的應用程序。因此，需要確定哪些內部 Web 服務器的功能能夠在內部防火牆以內訪問，而哪些功能能夠被內部防火牆以外的外部用戶訪問。
　　這些 ASP.NET 和 Windows 應用程序能夠使用 .NET Web 服務提供的功能。在這種情況下，確定哪些服務只能本地訪問（只爲 intranet 用戶提供）而哪些 Web 服務可以在 intranet 以外訪問。
　　但是，確定過程並不止這些。使一個 Web 服務可用並不意味着該服務對任何類型的使用方式都開放。必須按照上下文確定什麼是“私有“和“公有”。然後，可以將 Web 服務分爲幾個主要的組：
　　私有 Web 服務只對預定義的運行在所選的 Web 服務器上的 ASP.NET 應用程序可用。
　　私有 Web 服務只對預定義的 .NET 應用程序可用。這與上一種情況一致，因爲 ASP.NET 應用程序和 Windows 應用程序可以被看作相同 Web 服務純粹的消費者。
　　私有 Web 服務對任何被設計在 intranet 上運行的應用程序可用。
　　公有 Web 服務只對運行在所選公有 Web 服務器上的預定義 ASP.NET 應用程序可用，但對於其它應用程序不可用。
　　公有 Web 服務對於任何能夠訪問該服務宿主服務器的應用程序可用。
　　爲基礎結構和平臺組件服務的 Web 服務應該放置在本地 intranet 中。它們能夠被完全發現，因爲在 intranet 內部訪問它們已經受到了保護。但是，放置在私有局域網以外的公有 Web 服務應該只暴露有限的被發現能力。相似的考慮也適用於私有和公有 .NET Web 應用程序，因爲必須考慮哪些只能供企業用戶使用，哪些可以供外部用戶使用。
　　在某些情況下，您也許想在 intranet 應用程序中用 .NET Remoting 來代替 Web 服務。要了解 Remoting 和 Web 服務的對比，請參閱 Microsoft Web 站點 ( http://msdn.microsoft.com/library/en-us/dnadvnet/html/vbnet10232001.asp) 。 Web 服務是運行於不同平臺的應用程序間通信的理想選擇，而 Remoting 在基於 .NET 的應用程序之間的通信會更有效和可靠。
　　在任何情況下，確定每個組件將使用什麼驗證方法以及怎樣驗證使用該方法驗證那些資源也是非常重要的。可以用程序來確定，這樣在部署階段這些設置將不能改變。但是在部署階段，可以通過修改配置文件來定製這些設置，本文將後面將進行論述。
　　設計和管理一個 .NET 測試實驗室
　　要測試一個部署規劃的可行性，方便的辦法是運行一個試驗部署項目。該試驗項目的目的是在不需要面對產品環境的情況下跟蹤和解決任何潛在的問題並精細調整部署過程。該階段對於達到部署目標、保持進度、不超出預算邊界來說都是至關重要的。
　　.NET 測試實驗室應該是產品環境的一個複製品，包括最終所包含的所有的網絡層次和系統。越接近產品環境，試驗項目的效率就越高。
　　試驗項目穩定以後，部署團隊就能夠獲得最終的可行性。該階段的重要事件是：
　　功能規格的完成和穩定
　　概念驗證的完成
　　產前測試完成
　　試驗完成
　　風險管理規劃更新
　　您可能想開發額外的文檔來輔助將要進行部署的操作團隊。這些文檔可能包括：
　　培訓計劃
　　支持或問詢規劃
　　操作轉換規劃
　　災難恢復規劃
　　在該階段，部署規劃將是一個隨着測試程序進行中發生的連續變化而變化的動態規劃。應該特別注意災難恢復規劃，它應該被全面測試並嘗試預測和解決所有已知的潛在問題。
　　獲取反饋
　　爲了幫助確定是否超出了試驗項目，需要從試驗所包含的所有小組獲取反饋。可以使用不同的技術來獲取這些反饋，例如：
　　 Web 站點反饋表單
　　與業務經理的會議
　　問題報告
　　調查
　　對 IT 項目和網絡操作的觀測
　　試着從各個角度獲取儘可能多的部署該 .NET 解決方案信息，例如：
　　培訓
　　首發過程
　　支持
　　通訊
　　發生的問題
　　改進的建議
　　產品首發
　　部署項目的最後階段是產品首發。在這個階段，作爲試驗程序的一部分已經測試了所有任務，並且定義了所有風險和意外事故規劃。由於測試實驗室與真實地產品環境之間的區別，需要繼續測試並且已經在調整測試項目中初始化的過程。
　　產品首發過程應該在產品首發首發規劃中全面文檔記錄，包括不同組件是如何部署的詳細信息。應特別關注組件之間的依賴性，如果存在依賴性，要清楚地詳細說明部署的順序。已經在測試實驗室測試過的災難恢復規劃在該階段可做精細調整已符合產品環境的實際情況。
　　在部署完畢併爲執行主管準備好項目完結報告之後，應進行一次項目複查。項目複查可以客觀地反映整個項目的優勢和弱點，並分析如何運用獲得的知識和經驗提高將來基礎結構的部署水平。
　　
　　在 Visual Studio .NET 中部署項目
　　要使用 Windows 安裝程序部署 .NET 應用程序，可以使用 Visual Studio .NET 中的安裝和部署項目之一，如圖 4 所示：
　　

　　
　　圖 4 ：用 Visual Studio .NET 添加一個安裝項目
　　
　　 安裝項目爲一個基於 Windows 的應用程序創建了一個 Windows 安裝程序項目。
　　 Web 安裝項目創建了一個 Windows 安裝程序 Web 項目，在開發過程中可以手動向該項目添加文件
　　 合併模塊項目將可能被多個應用程序共享的組件打包。
　　 安裝嚮導幫助開發者一步一步創建安裝項目。
　　 Cab 項目爲舊式的 Web 瀏覽器準備 Cab 文件。
　　爲 Web 部署創建一個項目後（在 VS.NET 集成開發環境中叫做 Web 安裝項目），不能將它轉換爲一個 Windows 安裝程序項目（在 VS.NET 集成開發環境中叫做安裝項目），反之亦然。要獲取這樣的功能，必須創建兩個不同的安裝項目。使用安裝嚮導來創建一個直接安裝程序；但是，所有其它項目類型提供了極大地靈活性。
　　安裝程序提供了幾個編輯器。通過從安裝項目上下文菜單中選擇相應的項目來查看這些編輯器，如圖 5 所示
　　