.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]特性。