An explanation of the ASP. config file

Analysis:

configuration information for. NET Web applications, such as the most common settings for how to authenticate an ASP. Web application, can appear in every directory in the application. When you create a new Web application through vb.net, by default, a default Web. config file is automatically created in the root directory, including the default configuration settings, and all subdirectories inherit its configuration settings. If you want to modify the configuration settings for subdirectories, you can create a new Web. config file under that subdirectory. It can provide configuration information other than the configuration information inherited from the parent directory, or you can override or modify the settings defined in the parent directory.
Modifications to the Web. config file at run time do not need to restart the service to take effect (note:<processmodel> section exception). Of course, the Web. config file can be extended. You can customize the new configuration parameters and write configuration section handlers to process them.

One, Web. config configuration file (default configuration settings)

All of the following code should be located between the following code, in order to be more concise, the following example omits this XML tag.

< configuration>
  < system.web>
  < /system.web>
< /configuration>

1. <authentication> Festival

Role: Configure ASP. NET authentication support (for Windows, Forms, PassPort, none of the four). This element can only be declared at the machine, site, or application level. <authentication> elements must be used in conjunction with the <authorization> section.

Eg: The following example configures the site for forms-based authentication, and when no logged-on user accesses a webpage that requires authentication, the webpage automatically jumps to the landing page.

< authentication mode="Forms">
  < forms loginUrl="logon.aspx" name=".FormsAuthCookie"/>
< /authentication>

where element loginurl represents the name of the landing page, name indicates the cookie name.

2. <authorization> Festival

Role: Controls client access to URL resources (such as allowing anonymous user access). This element can be declared at any level (computer, site, application, subdirectory, or page). Must be used in conjunction with the <authentication> section.
Example: The following example disables access for anonymous users

< authorization>
 < deny users="?"/>
< /authorization>

Note: You can use User.Identity.Name to obtain the current user name that has been verified, and you can use the Web.Security.FormsAuthentication.RedirectFromLoginPage method to redirect the authenticated user to the page that the user just requested.

3. <compilation> Festival

Function: Configures all compilation settings used by ASP. The default Debug property is "true". It should be set to true after the program has been compiled for delivery (the Web. config file has a detailed description, omitting the example here)

4. <customErrors>

Role: Provides information about custom error messages for ASP. It does not apply to errors that occur in XML Web services.
Example: When an error occurs, the Web page jumps to the custom error page.

< customErrors defaultRedirect="ErrorPage.aspx" mode="RemoteOnly"> 
< /customErrors>

where element defaultredirect represents the name of the custom error page. The mode element indicates that custom (friendly) information is displayed for users who are not running on the local Web server.

5.

Role: Configure the ASP. NET HTTP runtime settings. This section can be declared at the machine, site, application, and subdirectory levels.
Example: Control user upload file up to 4M, maximum time 60 seconds, maximum number of requests is 100.

6. <pages>

Role: Identifies page-specific configuration settings (such as whether session state is enabled, view state, whether user input is detected, and so on). <pages> can be declared at the machine, site, application, and subdirectory levels.
Example: Do not detect a user's input in the browser for potentially dangerous data (note: The item is detected by default, if you use no detection, one to encode or verify the user's input), the encrypted view state is checked when the page is posted back from the client to verify that the view state has been tampered with on the client. (Note: This item is not verified by default)

< pages buffer= "true" enableviewstatemac= "true" validaterequest= "false"/>

7. <sessionState>

Role: Configures session state settings for the current application (such as setting whether session state is enabled, session state save location).
Example:

< sessionState mode="InProc" cookieless="true" timeout="20"/>
< /sessionState>

Note:
Mode= "InProc" means: Store session state locally (you can also choose to store it in a remote server or SAL server or do not enable session state)
Cookieless= "True" indicates that session state is enabled if the user's browser does not support cookies (default = False)
Timeout= "20" indicates the number of minutes that a session can be idle

8. <trace>

Role: Configure the ASP. NET tracking service, mainly used for program testing to determine where errors.
Example: The following is the default configuration in Web. config:

< trace enabled= "false" requestlimit= "pageoutput=" false "tracemode=" SortByTime "localonly=" true "/>

Note:
Enabled= "false" means no tracing is enabled; requestlimit= "10" indicates the number of trace requests stored on the server
Pageoutput= "false" means that trace output can only be accessed through the trace utility;
Tracemode= "SortByTime" indicates that trace information is displayed in the order in which the traces are processed;
Localonly= "True" indicates that the trace viewer (Trace.axd) is used only for hosting WEB servers;

9. <system.webServer>

<system.webServer>
  <security>
   <requestFiltering>
    <requestLimits maxAllowedContentLength="2147483648"/>
   </requestFiltering>
  </security>
</system.webServer>

Ii. custom Web. config file configuration section
Customizing the Web. config file configuration section is a two-step process.

The first is to declare the name of the configuration section between the <configSections> and </configSections> tags at the top of the configuration file and the name of the. NET Framework class that handles the configuration data in that section.

The second is to make the actual configuration settings for the declared section after the <configSections> area.

Example: Creating a section to store a database connection string

< configuration>  
 < configSections>  
  < section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>  
 < /configSections> 
 < appSettings>  
  < add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/>  
  < /appSettings>  
 < system.web>  
  ......  
 < /system.web>  
< /configuration>

Iii. accessing the Web. config file

You can access the Web. config file example by using the ConfigurationSettings.AppSettings static string collection: Gets the connection string established in the example above.

Iv. creating a Web. config file

1. In Solution Explorer, click the Refresh icon to confirm that the application does not yet have a Web. config file.

If you have used the Web Site Administration tool or some other way to configure your application, the Web. config file may have been created automatically. Click Refresh to update the file list.

2. In Solution Explorer, right-click the site name, and then click Add New Item.
3. In the Templates window, click Web configuration file

The file name in the Name text box should be Web. config. You can provide a different name for the file, but this is the default name. The. config file name extension prevents ASP. NET from downloading the appropriate file.
4. Click Add to create the file, and then open it for editing.

The file contains the code shown in the "Examples" section later in this topic and has some initial default values. The application inherits all configuration settings from the Machine.config and Web. config files in the%systemroot%\microsoft.net\framework\< version >\config directory. However, these default settings are not visible here. If you want to override inherited default settings or add collection elements such as the httphandlers element (ASP. NET setting Schema), you only need to create the application-level and directory-level Web. config files.

To view all the configuration settings for the current application, you can run the topic How to: Programmatically View inherited configuration settings and code that is contained in local configuration settings. You can also view the Machine.config.comments or Web.config.comments in the%systemroot%\microsoft.net\framework\< version >\config directory File (these two files also contain useful comments), but these two files will not contain all runtime settings, see How to: Programmatically View inherited configuration settings and local configuration settings.

5. If the Web. config file is changed, save the file.

Saving the Web. config file restarts the application. You can also choose to point to a secondary profile using the ConfigSource property of a single section element, and changing the secondary profile does not cause the application to restart. For more information, see ConfigSource in the General properties inherited by section elements.

Web. config is an important configuration file in an ASP. Web. config file allows us to develop and deploy ASP. Through the introduction of this article, I hope to help you, for reference.