開發與生產環境間的常見設定差異 (VB)

  • 發行項

作者：Scott Mitchell

下載 PDF

在先前的教學課程中，我們將所有相關檔案從開發環境複製到生產環境，藉此部署網站。 不過，環境之間的設定差異並不常見，這需要每個環境都有唯一的 Web.config 檔案。 本教學課程會檢查一般設定差異，並查看維護個別組態資訊的策略。

簡介

最後兩個教學課程逐步解說部署簡單的 Web 應用程式。 使用 FTP 用戶端部署您的網站教學課程示範如何使用獨立 FTP 用戶端，將必要的檔案從開發環境複製到生產環境。 上述教學課程： 使用 Visual Studio 部署您的網站，查看使用 Visual Studio 的 [複製網站] 工具和 [發佈] 選項進行部署。 在這兩個教學課程中，生產環境中的每個檔案都是開發環境中的檔案複本。 不過，生產環境中的組態檔與開發環境中的組態檔不同並不常見。 Web 應用程式的組態會儲存在檔案中 Web.config ，通常包含外部資源的相關信息，例如資料庫、Web 和電子郵件伺服器。 它也會在特定情況下拼字說明應用程式的行為，例如發生未處理的例外狀況時要採取的動作。

部署 Web 應用程式時，請務必讓正確的組態資訊最終出現在生產環境中。 在大部分情況下， Web.config 開發環境中的檔案無法依原樣複製到生產環境。 相反地，自定義版本的 Web.config 必須上傳至生產環境。 本教學課程會簡短檢閱一些較常見的組態差異;它也摘要說明一些技術，以維護環境之間的不同組態資訊。

開發和生產環境之間的一般設定差異

此 Web.config 檔案包含 ASP.NET 應用程式的組態資訊種類。 不論環境為何，此組態資訊都相同。 例如，不論環境為何，檔案<authentication>和元素中Web.config拼出的驗證設定和 <authorization> URL 授權規則通常都相同。 但其他組態資訊，例如外部資源的相關信息，通常會根據環境而有所不同。

資料庫連接字串是根據環境而有所不同之組態資訊的主要範例。 當 Web 應用程式與資料庫伺服器通訊時，它必須先建立連線，並透過 連接字串 達成。 雖然資料庫可以直接在網頁或連線至資料庫的程式代碼中硬式編碼 連接字串，但最好將其放在Web.config<connectionStrings>元素中，讓 連接字串 信息位於單一集中式位置。 開發期間通常會使用不同的資料庫，而不是在生產環境中使用;因此，每個環境 連接字串 信息必須是唯一的。

注意

未來的教學課程會探索部署數據驅動應用程式，此時我們將深入探討資料庫連接字串儲存在組態檔中的方式。

開發和生產環境的預期行為明顯不同。 開發環境中的 Web 應用程式正由一群開發人員建立、測試及偵錯。 在生產環境中，許多不同的同時用戶都會流覽相同的應用程式。 ASP.NET 包含一些功能，可協助開發人員測試和偵錯應用程式，但基於生產環境中時的效能和安全性原因，應該停用這些功能。 讓我們看看一些這類組態設定。

影響效能的組態設定

當第一次 (或第一次變更) 之後流覽 ASP.NET 頁面時，其宣告式標記必須轉換成類別，而且必須編譯此類別。 如果 Web 應用程式使用自動編譯，則也必須編譯頁面的程式代碼後置類別。 您可以透過 Web.config 檔案的 <compilation> 元素來設定編譯選項的種類。

偵錯屬性是 元素中最重要的屬性之 <compilation> 一。 debug如果屬性設定為 「true」，則編譯的元件會包含偵錯符號，在 Visual Studio 中偵錯應用程式時需要。 但偵錯符號會增加元件的大小，並在執行程式代碼時施加額外的記憶體需求。 此外，當 debug 屬性設定為 「true」 時，不會快取傳 WebResource.axd 回的任何內容，這表示每次使用者瀏覽頁面時，都必須重新下載 所 WebResource.axd傳回的靜態內容。

注意

WebResource.axd 是 ASP.NET 2.0 中引進的內建 HTTP 處理程式，伺服器控件會用來擷取內嵌資源，例如腳本檔案、影像、CSS 檔案和其他內容。 如需運作方式 WebResource.axd 以及如何使用它從自定義伺服器控制項存取內嵌資源的詳細資訊，請參閱使用 WebResource.axd透過URL存取內嵌資源。

元素 <compilation> 的屬性 debug 通常會在開發環境中設定為 「true」。 事實上，此屬性必須設定為 「true」，才能對 Web 應用程式進行偵錯;如果您嘗試從 Visual Studio 對 ASP.NET 應用程式進行偵錯，且 debug 屬性設定為 “false”，Visual Studio 會顯示一則訊息，說明在屬性設定為 “true” 之前 debug ，應用程式無法偵錯，而且會提供為您進行這項變更。

在生產環境中，您絕對不應該debug將 屬性設定為 「true」，因為其對效能的影響。 如需本主題的更完整討論，請參閱 Scott Guthrie 的部落格文章：請勿使用 Enabled 執行生產環境 ASP.NET 應用程式debug="true"。

自訂錯誤和追蹤

在 ASP.NET 應用程式中發生未處理的例外狀況時，它會泡泡到運行時間，此時會發生三件事之一：

  • 會顯示泛型運行時間錯誤訊息。 此頁面會通知用戶發生運行時錯誤，但不會提供錯誤的任何詳細數據。
  • 隨即顯示例外狀況詳細數據訊息，其中包含剛才擲回之例外狀況的相關信息。
  • 隨即顯示自定義錯誤頁面，這是您建立的 ASP.NET 頁面，會顯示您想要的任何訊息。

面對未處理的例外狀況會發生什麼情況，取決於 Web.config 檔案的 <customErrors> 區段。

開發和測試應用程式時，有助於查看瀏覽器中任何例外狀況的詳細數據。 不過，在生產環境的應用程式中顯示例外狀況詳細數據是潛在的安全性風險。 此外，它不會擴充，並讓您的網站看起來不具專業性。 在理想情況下，在未處理的例外狀況中，開發環境中的 Web 應用程式會顯示例外狀況的詳細數據，而生產環境中的相同應用程式會顯示自定義錯誤頁面。

注意

默認 <customErrors> 區段設定只會在透過localhost瀏覽頁面時顯示例外狀況詳細資料訊息，否則會顯示一般運行時間錯誤頁面。 這並不理想，但請務必知道預設行為不會向非本機訪客顯示例外狀況詳細數據。 未來的教學課程會更詳細地檢查區 <customErrors> 段，並示範如何在生產環境中發生錯誤時顯示自定義錯誤頁面。

另一個 ASP.NET 在開發期間很有用的功能是追蹤。 如果已啟用追蹤，則會記錄每個傳入要求的相關信息，並提供特殊網頁， Trace.axd以檢視最近的要求詳細數據。 您可以透過 <trace> 中的Web.config項目開啟及設定追蹤。

如果您啟用追蹤，請確定已在生產環境中停用。 由於追蹤資訊包含 Cookie、會話數據和其他潛在敏感性資訊，因此請務必在生產環境中停用追蹤。 好消息是預設會停用追蹤，而且檔案 Trace.axd 只能透過localhost存取。 如果您在開發中變更這些預設設定，請確定它們已在生產環境中關閉。

維護個別組態信息的技術

在開發和生產環境中有不同的組態設定會使部署程序複雜。 在前兩個教學課程中，部署程式牽涉到將所有必要的檔案從開發複製到生產環境，但只有在這兩個環境中的組態資訊相同時，此方法才能運作。 有各種不同的技術可用來部署具有不同組態資訊的應用程式。 讓我們為裝載的 Web 應用程式編錄其中一些選項。

手動部署生產環境組態檔

最簡單的方法是維護兩個 Web.config 版本的檔案：一個用於開發環境，另一個用於生產環境。 將月臺部署到生產環境需要將所有檔案複製到開發環境中的生產伺服器， 但 檔案 Web.config 除外。 相反地，生產環境特定的 Web.config 檔案會複製到生產環境。

這種方法並不複雜，但很容易實作，因為設定資訊不常變更。 最適合使用裝載於單一 Web 伺服器上的小型開發小組的應用程式，且其組態資訊不常變更。 使用獨立 FTP 用戶端手動部署應用程式檔案時，這是最可行的。 使用 Visual Studio 的 [複製網站] 工具或 [發佈] 選項時，您必須先將部署特定檔案與生產特定 Web.config 檔案交換，再部署完成，然後在部署完成之後將它們交換回。

在建置或部署程式期間變更設定

到目前為止，討論已假設臨機操作的建置和部署程式。 許多較大的軟體專案都有更正式的程式，可利用開放原始碼、家用或第三方工具。 針對這類專案，您可以自定義建置或部署程式，以在將組態資訊推送至生產環境之前，適當地修改設定資訊。 如果您使用 MSBuild、 NAnt 或其他建置工具建置 Web 應用程式，您可以新增建置步驟來修改 Web.config 檔案以包含生產特定設定。 或者，您的部署工作流程可以程序設計方式連線到原始檔控制伺服器並擷取適當的 Web.config 檔案。

針對生產環境取得適當設定資訊的實際方法，會根據您的工具和工作流程而有所不同。 因此，我們不會進一步探討本主題。 如果您使用 MSBuild 或 NAnt 等熱門建置工具，您可以透過 Web 搜尋找到這些工具專屬的部署文章和教學課程。

透過 Web 部署專案管理組態差異 Add-In

在 2006 年，Microsoft 發行了適用於 Visual Studio 2005 的 Web Development Project Add-In。 Visual Studio 2008 Add-In 於 2008 年發行。 此 Add-In 可讓 ASP.NET 開發人員在其 Web 應用程式專案旁邊建立個別的 Web 部署專案，此專案會在建置時明確編譯 Web 應用程式，並複製檔案以部署至本機輸出目錄。 Web 應用程式專案會在幕後使用 MSBuild。

根據預設，開發環境的 Web.config 檔案會複製到輸出目錄，但您可以設定 Web 部署專案來自定義

以下欄取到此目錄的群組態資訊：

  • 透過 Web.config 檔案區段取代，您可以在其中指定要取代的區段，以及包含取代文字的 XML 檔案。
  • 提供外部組態來源檔案的路徑。 選取此選項後，Web 部署專案會將特定 Web.config 檔案複製到輸出目錄 (，而不是 Web.config 開發環境中所使用的檔案) 。
  • 將自訂規則新增至 Web 部署專案所使用的 MSBuild 檔案。

若要部署 Web 應用程式，請建置 Web 部署專案，然後將檔案從專案的輸出資料夾複製到生產環境。

若要深入瞭解如何使用 Web 部署專案，請參閱 MSDN Magazine 2007 年 4 月問題中的此 Web 部署專案文章，或參閱本教學課程結尾的一節中的連結。

注意

您無法搭配 Visual Web 開發人員使用 Web 部署專案，因為 Web 部署專案會實作為 Visual Studio Add-In，而 Visual Studio Express 版本 (包括 Visual Web Developer) 不支援載入宏。

摘要

開發中 Web 應用程式的外部資源和行為通常與在生產環境中相同應用程式時不同。 例如，資料庫連接字串、編譯選項，以及在環境之間發生未處理的例外狀況時的行為通常不同。 部署程式必須容納這些差異。 如本教學課程中所討論，最簡單的方法是手動將替代組態檔複製到生產環境。 使用 Web 部署專案 Add-In 或更正式的組建或部署程式，以容納這類自定義專案時，可能會有更簡潔的解決方案。

快樂的程序設計！

深入閱讀

如需本教學課程中討論之主題的詳細資訊，請參閱下列資源：

上一個下一個