Introduction

The presence of the Web.config file in an ASP.NET application is not mandatory, but it is difficult to see an application that does not contain this file nowadays. Its function is solely and exclusively to be a file where we must store configurations linked to the main web project or sub-projects, containing element sets that can vary between connection to database, cache and application security.

Web.Config Structure

Generally located in the project’s default directory, Web.config can also be included in project sub-folders. Let’s look at the contents of a Web.config file below:

<?xml version="1.0"?>
<configuration>
    <system.web>
    	<compilation debug="true" Framework="4.5" />
      	<httpRuntime Framework="4.5" />
    </system.web>
</configuration>

If your application does not contain this file, its insertion can be done simply and quickly. Right click on your Web application, select Add> New item … or if you prefer use the shortcut key Ctrl + Shift + A, search for Web Configuration File and add it to your Web project.

Its structure must conform to an XML file, with no limitation as to its size. Before we start explaining some sections available in this configuration file, we need to understand the hierarchy behind a Web.config file in a Web application.

At the beginning of this post I said that its use was not explicitly required, but we are implicitly using this file because the .NET Framework has a file named Machine.config inside the .NET Framework directory (% SystemRoot% Microsoft.NETFramework <version.net> Config), this file has settings for all .NET Windows Forms, WPF, Console, Silverlight, Class Library), but there is a file hierarchically above with specific settings for a Web application, if this file contains sections that conflict directly with Machine.config, these sections are automatically overwritten by sections of the Web.config file, the same happens when we have a Web.config file contained in our apl If the sections conflict with the Web.config sections contained in the .NET Framework directory, the same process repeats itself.

But when does all this happen? Exactly when the Web application is hosted on IIS and it is started. It has been loading the configuration files from the bottom up, comparing the files and overriding the conflicting settings, at the end of this process IIS generates a configuration file that is in memory.

Configuration Sections

The sections contained in a Web.Config file, are not limited to the configuration character for database connections, caching or application security itself, goes far beyond that. All configuration sections must be within the </configuration> primary node.

Let’s take this code based on sen7ding email with Gmail using the SmptClient class:

var fromAddress = new System.Net.Mail.MailAddress("yourEmail@gmail.com", "Name");
var toAddress = new System.Net.Mail.MailAddress("emailTo@domain.com", "Name");

const string password = "pwd";
const string subjectContent = "Subject";
const string messageContent = "email send test";

var smtp = new System.Net.Mail.SmtpClient
{
    Host = "smtp.gmail.com",
    Port = 587,
    EnableSsl = true,
    DeliveryMethod = System.Net.Mail.SmtpDeliveryMethod.Network,
    UseDefaultCredentials = false,
    Credentials = new System.Net.NetworkCredential(fromAddress.Address, password)
};

using (var message = new System.Net.Mail.MailMessage(fromAddress, toAddress))
{
    message.Subject = subjectContent;
    message.Body = messageContent;

    smtp.Send(message);
}

The above code fulfills its function, which is justification the sending of e-mail. But if we think that one day the password of this email, which is used to authenticate in Smtp is changed, think of the work of changing this password in the code, compile the application, perform tests, generate the package to finally apply in production. We can use the configuration file of the application, as it has just a session to configure a standard Smtp that will be used alongside the SmptClient class implicitly, so that you can decentralize the Smtp settings of the code and leaving it with Web.config, see:

<system.net>
  <mailSettings>
    <smtp deliveryMethod="Network" from="yourEmail@gmail.com">
      <network
        host="smtp.gmail.com"
        userName="yourEmail@gmail.com"
        password="pwd"
        port="587"
        enableSsl="true"
        defaultCredentials="false"
      />
    </smtp>
  </mailSettings>
</system.net>