. Net basic learning (4): Elements in the web. config file of ASP. NET

The default format of the web. config file is as follows:

<? XML version = "1.0"?>

<Configuration>

<Appsettings/>

<Connectionstrings/>

<System. Web>

<Compilation DEBUG = "false"/>

<Authentication mode = "Windows"/>

</System. Web>

</Configuration>

 

Like any *. config file, Web. config defines the root-level <configuration> element. It can contain a large number of sub-elements to control web applications.ProgramHow to run it during running.

 

Part element of the web. config file
 
<Deleetask>
This element is used to establish custom name/value pairs so that they can be read to the memory programmatically for the page to use.
 
<Authentication>
This element can be used to configure the Security Authentication mode used by ASP. NET to identify the passed-in user.
<Authorization>
It is also a security-related element used to define which user can access the resources on the Web server.
 
<Compilation>
This element is used to enable (or disable) debugging and defines the default. NET language used by the web application. It can selectively define the External. Net assembly that should be automatically referenced.
 
<Connectionstrings>
This element is used to maintain the external connection string used within the site.
 
<Customerrors>
This element is used to accurately tell the runtime how to display errors that occur during the web application's work.
If an error is not processed during request execution, the developer can configure the HTML error page to display in this section to replace the error stack trace.

<Globalization>
This element is used to configure regionalization settings for the Web application.
 
<Sessionstate>
This element is used to control how and where session status data is stored by the. NET Runtime Library.
 
<Trace>
This element is used to enable (or disable) tracing support for the Web application.
 

For more information about the web. config format, see the "ASP. NET settings schema" topic in the. NET Framework 2.0 SDK documentation.

Use <trace> to enable Tracing

 

The first aspect to be introduced in the web. config file is the <trace> sub-element. This XML object can further limit its behavior with any number of features, as shown below:

<Trace enabled = "True | false"

Localonly = "True | false"

Pageoutput = "True | false"

Requestlimit = "integer"

Tracemode = "sortbytime | sortbycategory"/>
 
Enabled
Specifies whether to enable tracking for an entire application (the default value is false ). As mentioned in the previous chapter, you can use the @ page command to selectively enable tracing for a given *. aspx file.

You can use the <% @ page> command to enable a trail on a separate page. However, to enable tracking for all pages in a web application, you only need to update <trace> as follows:

<Trace

Enabled = "true"

Requestlimit = "10"

Pageoutput = "false"

Tracemode = "sortbytime"

Localonly = "true"

/>

Localonly
Indicates that the trace information is visible only on the host web server, but not on the remote client (the default value is true)
 
Pageoutput
Specify how to view Trace Output
 
Requestlimit
Specifies the number of trace requests that will be stored on the server. The default value is 10. If the limit is reached, the trail is automatically disabled.
 
Tracemode
Indicates that the trace information is displayed in the order it is processed. The default value is sortbytime, but it can also be configured to sort by type

Custom error output through <customerrors>

The <customerrors> element can be used to automatically redirect all errors to a custom *. htm file set. If you want to create an error page that is more user-friendly than the default page provided by CLR, you can use it. The <customerrors> element looks like this:

 
<Customerrors defaultredirect = "url" mode = "on | off | remoteonly">

<Error statuscode = "statuscode" Redirect = "url"/>

</Customerrors>
 

For example, for the use of the <customerrors> element, assume that the ASP. NET web application has two *. HTM files. The first file (genericerror.htm) is a page that captures all errors. Maybe this page contains a picture of your company's logo, a link to the system administrator who sent an email, and a lengthy apology letter. The second file (error404.htm) is a custom error page, which should only appear when the runtime detects Error Code 404 (terrible "resource not found" error. To ensure that all errors are processed by these custom pagesCodeUpdate the Web. config file:

 
<? 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>
 

Note: How does the root <mermerrors> element specify the name of a common page for all unprocessed errors. A feature that may appear in the start tag is mode. The default setting is remoteonly. If the HTTP request comes from the same machine as the Web server (this is very helpful for developers who want to see the details ), it indicates that the Runtime Library does not display a custom error page. When the mode feature is set to on, this will cause custom errors to be visible to all machines (including development tools ). Note that the <customerrors> element supports many nested <error> elements to specify which page will be used to process the specified error code.

To test these custom error redirection, build a *. ASPX page that defines two button parts, and then process the click events of the two controls as follows:

Private void btngeneralerror_click (Object sender, eventargs E)
{
// This will trigger a general error.
Throw new exception ("general error ...");

}

Private void btn404error_click (Object sender, eventargs E)
{
// This will trigger the 404 error (assuming there is no file named mypage. aspx ).
Response. Redirect ("mypage. aspx ");
}

 

Use the <sessionstate> storage status

The most powerful aspect of the web. config file is the <sessionstate> element. Asp.netuses the internal process *. dll hosted by asp.netjob (aspnet_wp.exe) to store the session status. And others *. like DLL, the good side is that you can access information as quickly as possible, but the disadvantage is that if the application domain crashes (for whatever reason), all user status data will be destroyed. In addition, when the stored status data is *. dll in a process, you cannot interact with a networked web farm. By default, the <sessionstate> element of the web. config file is as follows:
 
<Sessionstate

Mode = "inproc"

Stateconnectionstring = "TCPIP = 127.0.0.1: 42424"

Sqlconnectionstring = "Data Source = 127.0.0.1; trusted_connection = yes"

Cookieless = "false"

Timeout = "20"

/>

If a web application is hosted by a Web server host, the default storage mode is suitable. However, in asp.net, you can specify the runtime database to allow asp.netto session state server (aspnet_state.exe). This proxy process carries the session status *. dll. In this case, the *. dll can be detached from aspnet_wp.exe to a unique *. EXE. The first step is to start the aspnet_state.exe Windows service. You just need to enter the following in the command line:

Net start aspnet_state

You can also access services appletfrom the Administrative Tools Folder of the Control Panel to start aspnet_state.exe.

The primary advantage of this notebook is that when the computer starts using the notebook window, you can configure aspnet_state.exe to enable it automatically. In any case, once the session state server is running, you can modify the <sessionstate> element of the web. config file, as shown below:

 

<Sessionstate

Mode = "StateServer"

Stateconnectionstring = "TCPIP = 127.0.0.1: 42424"

Sqlconnectionstring = "Data Source = 127.0.0.1; trusted_connection = yes"

Cookieless = "false"

Timeout = "20"

/>

 

The mode feature has been set to StateServer. In this case, clrwill host session-related data in aspnet_state.exe. In this way, if the application domain hosting the web application crashes, the session data will be saved. Note that the <sessionstate> element also supports the stateconnectionstring feature. The default TCP/IP address (127.0.0.1) points to the local computer. If you wish to allow the .netruntime to use the aspnet_state.exe Service (Web farm) on another computer on the network, you can freely update this value.

Finally, if the web application requires the highest isolation and durability, you can have the runtime store all session status data to Microsoft SQL Server. It is very easy to update the web. config file properly:

 

<Sessionstate

Mode = "sqlserver"

Stateconnectionstring = "TCPIP = 127.0.0.1: 42424"

Sqlconnectionstring = "Data Source = 127.0.0.1; trusted_connection = yes"

Cookieless = "false"

Timeout = "20"

/>

However, when trying to run related web applications, make sure that the target computer (specified by the sqlconnectionstring feature) has been correctly configured. Install. net Framework 2.0 SDK (or Visual Studio 2005), there are two files available, installsqlstate. SQL and uninstallsqlstate. SQL. By default, they are located at <% WINDIR %> \ Microsoft. net \ framework \ <version number>. On the target computer, you must use tools such as SQL Server Query analyzer (released together with Microsoft SQL Server) to run the installsqlstate. SQL file.

Once you execute this SQL script, you will find that you have created a new SQL Server database (aspstate), which contains a large number of ASP. the stored procedure called by the net runtime database and the table used to store the session data itself (at the same time, the tempdb database has updated with a set of tables for the purpose of exchange ). As you may have guessed, configuring a web application to store session data to SQL Server is the slowest of all possible options. The advantage of doing so is that user data can be saved permanently as much as possible (even if the web server is restarted ).

note that if ASP.. Net session Status server or SQL server stores session data. Make sure that any custom type placed in the httpsessionstate object has been marked with the [serializable] feature.