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 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");
}
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]特性。
<?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]特性。
