.net基礎學習（四）：ASP.NET的Web.Config檔案中的元素

Web.Config檔案預設格式如下：

<?xml version="1.0"?>

<configuration >

  <appSettings/>

  <connectionStrings/>

  <system.Web>

    <compilation debug="false"/>

    <authentication mode="Windows"/>

  </system.Web>

</configuration>

 

像任何*.config檔案一樣，Web.config定義了根級的<configuration>元素。它能夠包含大量的子項目，用來控制Web應用程式在運行時應該怎樣運行。

 

Web.config檔案的部分子項目
 
<appSettings>
 該元素用於確立自訂成對的名稱和數值，這樣它們可以以編程方式讀進記憶體供頁面使用。
 
<authentication>
 該元素可以配置 ASP.NET 使用的安全身分識別驗證模式，以標識傳入的使用者。
<authorization>
 也是和安全相關聯的元素，用於定義哪一個使用者可以訪問Web伺服器上的哪些資源。
 
<compilation>
 該元素用於啟用（或禁用）調試，並定義由該Web應用程式使用的預設.NET語言，它可以選擇性地定義應該被自動引用的外部.NET程式集。
 
<connectionStrings>
 該元素用於保持在該網站內使用的外部連接字串。
 
<customErrors>
 該元素用於準確地告知運行庫如何顯示在Web應用程式工作期間出現的錯誤。
 如果在執行請求的過程中出現未處理的錯誤，開發人員通過該節可以配置要顯示的 html 錯誤頁以代替錯誤堆疊追蹤。

<globalization>
 該元素用於對該Web應用程式配置全域化的各項設定。
 
<sessionState>
 該元素用於控制以何種方式和在何處將由.NET運行庫儲存工作階段狀態資料。
 
<trace>
 該元素用於對該Web應用程式啟用（或禁用）跟蹤支援。
 

注   關於Web.config格式的細節請查看.NET Framework 2.0 SDK文檔內的“ASP.NET Settings Schema”話題。

通過<trace>啟用跟蹤

 

Web.config檔案中第一個要介紹的方面就是<trace>子項目。這個XML實體可以用任何數量的特性進一步限定它的行為，如下所示：

<trace enabled="true|false"

  localOnly="true|false"

  pageOutput="true|false"

  requestLimit="integer"

  traceMode="SortByTime|SortByCategory"/>
 
enabled
 指定是否對作為一個整體的應用程式啟用跟蹤（預設設定值為false）。在前一章提到，可以對一個給定的*.aspx檔案使用@Page指令有選擇性地啟用跟蹤

單獨的頁面可以使用<%@page>指令啟用跟蹤。然而，如果希望在Web應用程式中使所有的頁面都啟用跟蹤功能，只需簡單更新<trace>，如下所示：

<trace

  enabled="true"

  requestLimit="10"

  pageOutput="false"

  traceMode="SortByTime"

  localOnly="true"

/>

localOnly
 指明跟蹤資訊僅在宿主Web伺服器上可見，而在遠端客戶機上不可見（預設設定值為true）
 
pageOutput
 指定應該如何查看跟蹤輸出
 
requestLimit
 指定將儲存在伺服器上的跟蹤請求的數量，預設值為10。如果達到極限，跟蹤就自動禁用
 
traceMode
 指明跟蹤資訊以其被處理的順序顯示。預設值為SortByTime，但也可進行配置使得它按照種類排序

通過<customErrors>自訂錯誤輸出

<customErrors>元素可以用來自動將所有錯誤重新導向到一個自訂的*.htm檔案集中。如果你希望建立一個比CLR提供的預設頁面更方便使用的錯誤頁面的話，就可以用到它。<customErrors>元素的外觀大體如下所示：

 
<customErrors defaultRedirect="url" mode="On|Off|RemoteOnly">

<error statusCode="statuscode" redirect="url"/>

</customErrors>
 

例如<customErrors>元素的用處，假設ASP.NET Web應用程式有兩個*.htm檔案。第一個檔案（genericError.htm）是一個捕獲所有錯誤的頁面。可能這個頁麵包含了一個你的公司的標誌圖片，一個寄送電子郵件到系統管理員的連結，還有一封冗長的道歉信。第二個檔案（Error404.htm）是一個自訂的錯誤頁面，它應該僅在運行時探測到錯誤編號404（可怕的“資源沒有發現”錯誤）時出現。現在，如果要確保所有的錯誤被這些自訂頁面處理，可以按如下代碼所示更新Web.config檔案：

 
<?xml version="1.0"?>

<configuration >

<appSettings/>

<connectionStrings/>

<system.Web>

<compilation debug="false"/>

<authentication mode="Windows"/>

<customErrors defaultRedirect = "genericError.htm" mode="On">

<error statusCode="404" redirect="Error404.htm"/>

</customErrors>

</system.Web>

</configuration>
 

注意，根<customErrors>元素是如何用來為所有未被處理的錯誤指定通用頁面的名字的。一個可能出現在開始標籤中的特性是mode。預設的設定是RemoteOnly，如果HTTP請求來自同一台作為Web伺服器的機器（這對於想要看細節的開發人員來說是非常有協助的），那麼它指示運行庫不顯示自訂錯誤頁。當設定mode特性為on時，這將導致自訂錯誤對所有機器可見（包括開發工具）。也要注意，<customErrors>元素可以支援許多嵌套<error>元素以指定哪個頁面將用來處理指定的錯誤碼。

為了測試這些自訂錯誤重新導向，構建一個定義兩個Button組件的*.aspx頁面，然後如下處理這兩個控制項的Click事件：

private void btnGeneralError_Click(object sender, EventArgs e)
{
    // 這將觸發一般錯誤。
  throw new Exception("General error...");

}

private void btn404Error_Click(object sender, EventArgs e)
{
    // 這將觸發404錯誤（假設沒有名為MyPage.aspx的檔案）。
  Response.Redirect("MyPage.aspx");
}

 

通過<sessionState>儲存狀態

Web.config檔案最強大的方面是<sessionState>元素。預設情況下，ASP.NET將使用由ASP.NET背景工作處理序（aspnet_wp.exe）承載的內部進程*.dll儲存工作階段狀態。與其他*.dll一樣，好的一面是可以儘可能快地訪問資訊，而缺點是，如果這個應用程式定義域崩潰了（不管什麼原因），所有的使用者狀態資料都會被銷毀。此外，當儲存狀態資料為一個進程內*.dll時，你不能與一個連網的Web farm互動。預設情況下，Web.config檔案的<sessionState>元素如下所示：
 
<sessionState

  mode="InProc"

  stateConnectionString="tcpip=127.0.0.1:42424"

  sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"

  cookieless="false"

  timeout="20"

/>

如果Web應用程式由一個Web伺服器主機承載，那麼這個儲存的預設模式正好合適。然而，在ASP.NET下，你可以指定運行庫讓ASP.NET工作階段狀態伺服器（aspnet_state.exe）這個代理進程承載工作階段狀態*.dll。這麼做，能夠從aspnet_wp.exe將*.dll卸載到專屬的*.exe中。第一步是啟動aspnet_state.exe Windows服務。只需要簡單地在命令列輸入：

net start aspnet_state

另外，也可以從Control Panel的Administrative Tools檔案夾訪問Services applet來啟動aspnet_state.exe。

這個方法的主要優點是當電腦使用屬性視窗啟動時，你能夠通過配置aspnet_state.exe使其自動啟動。無論如何，一旦工作階段狀態伺服器運行起來，就可以修改Web.config檔案的<sessionState>元素，如下所示：

 

<sessionState

  mode="StateServer"

  stateConnectionString="tcpip=127.0.0.1:42424"

  sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"

  cookieless="false"

  timeout="20"

/>

 

這裡，mode特性已經設定為StateServer。此刻，CLR將在aspnet_state.exe內承載與會話相關的資料。在這種方式下，如果承載Web應用程式的應用程式定義域崩潰了，會話資料就會儲存下來。還要注意，<sessionState>元素也能支援stateConnectionString特性。預設的TCP/IP地址值（127.0.0.1）指向本機電腦。如果你願意讓.NET運行庫使用網路上另一台電腦上的aspnet_state.exe服務（又是Web farm），你可以自由更新這個值。

最後，如果要求Web應用程式具有最進階的隔離性和持久性，你可以讓運行庫將所有工作階段狀態資料存放區到Microsoft SQL Server中。對Web.config檔案做適當的更新非常簡單：

 

<sessionState

  mode="SQLServer"

  stateConnectionString="tcpip=127.0.0.1:42424"

  sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"

  cookieless="false"

  timeout="20"

/>

然而，在開始嘗試運行相關的Web應用時，先需要確保目標電腦（由sqlConnectionString特性指定）已經得到正確的配置。安裝.NET Framework 2.0 SDK（或Visual Studio 2005）時，有兩個檔案可供選擇，InstallSqlState.sql和UninstallSqlState.sql，預設情況下，它們位於<%windir%>\Microsoft.NET\ Framework\<版本號碼>。在目標電腦上，必須使用如SQL Server 查詢分析器（與Microsoft SQL Server一起發布的）等工具來運行InstallSqlState.sql檔案。

一旦執行了這個SQL指令碼，你將發現已經建立了一個新的SQL Server資料庫（ASPState），它包含大量被ASP.NET運行庫調用的預存程序和一套用來儲存會話資料本身的表（同時，出於交換目的tempdb資料庫已經用一套表更新了）。你可能已猜到，配置Web應用程式將會話資料存放區到SQL Server是所有可能選項中最慢的。這麼做的好處是，使用者資料可以儘可能地持久儲存了（即使Web伺服器重啟了）。

注    如果使用ASP.NET工作階段狀態伺服器或SQL Server儲存會話資料，必須確認任何放置在HttpSessionState對象內的自訂類型已經被標記了[Serializable]特性。