Web.Config file settings:

The web.config file is a critical component for all but the simplest .NET web applications. It has two main functions, to store information about the website itself – things like scripting language used, .NET components available to the site, etc. and to store configuration information for the site – database connection strings, etc.

The file has grown as .NET has developed. Each new version of the .NET library has increased the complexity of the file, and in a short article like this it’s only possible to explore a part of what’s available to us. So, I’m focussing on what I call the ‘core’ of the config file, a basic file for use with ASP.NET websites based around the .NET 2 Framework.

Starting Off

Within the Visual Studio IDE or Visual Web Developer a ‘bare bones’ web.config file can be created by choosing to create an empty web site. This basic config file is VERY basic (comments removed):

<?xml version="1.0"?>
 <configuration>
 <appSettings/>
 <connectionStrings/>
<system.web>
 <compilation debug="true"/>
 <authentication mode="Windows"/>
</system.web>
</configuration>

This file does, however, give us the basic structure:

• AppSettings – stores settings for your particular application.
• ConnectionStrings – stores data source connection strings.
• System.web – web server configuration for this particular application – the stuff that used to require changes to IIS.

Later versions of the file contain additional entries in the system namespace, such as system.webServer used by sites running AJAX under IIS7, but we won’t be looking at these sections here.

Some facts about web.config:

• The web.config file must be a well formed, XML file. If it isn’t, it will break the application.
• Any attempt by a user of the site to retrieve it by typing the file name in as a URL will be bounced back with Access Denied.
• web.config files operate over the folder they’re in and all child folders. Sites may have more than one web.config file, in different folders, giving varying degrees of configuration control over the site.
• Changes in the web.config file do not need a restart of IIS on a production server to take effect.

A more realistic web.config file is generated for you automatically when you create a new ASP.NET website within the IDE.

AppSettings

This stores site level configuration information – for example, the default credentials required to log on to a service used by the site. Whilst this sort of information can be hard-coded into a page, it’s better practice to put the details in the config file.

<appSettings>
 <add key="mailname" value="fred@mydomain.com"/>
 <add key="mailpassword" value="password"/>
 <add key="mailserver" value="mail.mydomain.com"/>
</appSettings>

The settings in this part of the file can be retrieved in your code by a line like:

Dim sMailServer AsString= ConfigurationManager.AppSettings("mailserver")

ConnectionStrings

Quite why web.config has a separate section for connectionStrings and appSettings I have no idea – on different sites I have used appSettings for everything or connectionSettings for everything. However, the connectionSettings section is designed to take details of connection strings for database connections:

<connectionStrings>
<add name="MySqlServer" connectionString="Server=MICSLAPTOP;Database=CAPE-UK;Integrated Security=SSPI;Provider=SQLOLEDB;"/>
</connectionStrings>

You get at the connection string by a line of code like:

Dim strConn AsString= ConfigurationManager.ConnectionStrings("MySqlServer").ConnectionString

System.web

There are a few items in this section that can be very useful when developing. The first is the compilation directive:

<compilation debug="false" strict="false" explicit="true"/>

Here, ‘debug’ indicates whether debugging information will be made available or not. This should be set to false in a production environment, as it has an impact on performance. However, it can be set to ‘true’ in development, ‘strict’ ensures some degree of ‘Type Safety’ within the application. Setting it to true will prevent conversions between data types that have the potential for data loss from taking place. E.g. between a 64bit and 32 bit integer, for example. ‘explicit’, when set to ‘true’ forces the declaration of all variables used in the application. When set to ‘false’ you can use a variable without declaring it.

Another useful section is the customErrors section:

<customErrors mode="RemoteOnly" defaultRedirect="/myerrorpage.htm">
<error statusCode="404" redirect="/mypagenotfound.htm"/>
<error statusCode="403" redirect="/myaccessdeniedpage.htm"/>
</customErrors>

This particular section will apply to remote users of the web site i.e. anyone not on the server or development machine and will change the way the site handles errors for those users. Any error in the .NET code will result in the user being shown the contents of ‘myerrorpage.htm’. This is a good move from the point of view of security, as it stops people getting any inkling of how your site works by forcing errors. Mypagenotfound.htm will be displayed rather than the generic ‘Page Not Found’ message from the server, and the contents of ‘myaccessdeniedpage.htm’ will be displayed rather than the usual ‘Access Denied’ message.

There are several other options available in the web.config file, but these detailed here will give you improved functionality and reliability of your site.