I would like to share what I have understood about working with more than one Web.config file from my latest ASP.NET application.
The ASP.NET Web.config file is used to define the configuration settings for an ASP.NET application. ASP.NET and the .NET Framework use .config files to define all configuration options. The .config files, including the ASP.NET Web.config file, are XML files.
Server-wide configuration settings for the .NET Framework are defined in a file called Machine.config. The settings in the Machine.config file can be changed and those settings affect all .NET applications on the server.
Different ASP.NET applications might need different application settings, that’s why defining those settings in the Machine.config file, is usually not practical. The solution for this problem is the ASP.NET Web.config file.
The ASP.NET application configuration settings can be changed by creating a file called Web.config and saving it in the root folder of the application. But what if the Machine.config file defines different settings than the ones defined in your Web.config file? The good news is that the settings in the Web.config file override the settings in the Machine.config file.
This is how the minimal Web.config file should look like:
<?xml version="1.0" encoding="utf-8" ?>
The first line of the Web.config file is the same as the first line for any .config file and specifies that this is an XML document with utf-8 character encoding type.
There are 2 important characteristics of the Web.config file. The first one is that if you change your Web.config file, you don’t need to re-compile your ASP.NET application.
The second one is that the Web.config file cannot be viewed in directly in a browser.
How can we use the ASP.NET Web.config file?
<appSettings> Web.config section
The ASP.NET Web.config file is a perfect place to store your ASP.NET application configuration settings. For example you can store your database connection string in Web.config file and access them easily from your ASP.NET application. Why would you want to keep your database connection strings in the Web.config file? The reason is simple – easier maintenance and deployment. Imagine that you have a huge ASP.NET application, with several hundreds pages connecting and interacting with a database. If all those pages have the database connection string hard-coded in them, it will be a nightmare to change all those strings in case you are changing database servers. Using the Web.config file to store the database connection strings will allow you to change the connection string only once, and you don’t have to even re-compile the whole application. Of course you can keep any application wide settings in your Web.config file, not only database connection strings.
Consider the Web.config example below:
<?xml version="1.0" encoding="utf-8" ?>
<add key="sConnectionString" value="Provider=SQLOLEDB;DataSource=Your_Server_Name;Initial Catalog=Your_Database_Name;User Id=Your_Username;Password=Your_Password;" />
As you can see, we have added a new section in our Web.config called <appSettings>.
The <appSettings> section defines custom ASP.NET application settings. The <add> child element of the <appSettings> ads a key/value pair, which is accessible from your applications, with the following code:
<customErrors> Web.config section
The <customErrors> section of the Web.config file defines the settings for handling web application errors. Below is the general syntax of this section:
<customErrors defaultRedirect="YourDefaultURL" mode="On|Off|RemoteOnly">
<error statusCode="ErrorStatusCode" redirect="YourRedirectURL"/>
The attribute mode defines how custom error handling works and can be one of the following 3 options:
RemoteOnly: Enabled only for remote clients (requests coming from the local machine are not handled by these custom error settings).
You can use the <customErrors> Web.config section to define how to handle particular error codes. Here is an example of custom handling of 404 error (File Not Found):
<error statusCode="404" redirect="Nice-FileNotFound-Page.aspx"/>
<identity> Web.config section
The <identity> Web.config section defines what identity (Windows account) to use when accessing the ASP.NET application. Here is the generic syntax of the <identity> section of the Web.config:
<identity impersonate="true|false" userName="username" password="password"/>
Impersonation is the concept whereby an application executes under the context of the identity of the client that is accessing the application. This is achieved by using the access token provided by IIS.
By default the ASPNET Windows account is used to access ASP.NET resources through the Aspnet_wp.exe process. This account is less powerful, compared to the IUSR_ machinename guest Internet account used by classic ASP for example. In certain situations you might want to use the anonymous IUSR_ machinename account, as the account accessing your ASP.NET application and you can do that by using the following code in your Web.config file:
<identity impersonate="true" />
In this case we use impersonation. In short impersonation is the act of ASP.NET executing code in the context of an authenticated client (Windows account).
If you want you can specify a particular account Windows account to be used instead of the ASPNET Windows account. You can do it like this:
<identity impersonate="true" userName="WindowsDomain\YourUserName" password="YourPassword" />
The ASP.NET Web.config file can control many more settings like Session State, Tracing and Authentication & Authorization for example.
Formatting edited by Webmaster on July 22, 2008.