Most ASP.NET applications include a number of configuration settings, such as connection strings, mail server settings, system-wide default settings, and so forth. While these settings could be hard-coded in the source code, it's usually a wiser idea to place them in a configuration file, such as Web.config. The reasoning being that if these values need to be modified, editing a configuration file is a lot easier than updating the code, rebuilding, and re-deploying.

We can define custom configuration sections in Web.config that conforms to a pre-determined XML schema. For example, our web application might have a couple of scalar configuration settings (quoteOfTheDay and yourAge) as well as a collection of settings (favoriteStates) where each setting in the collection can have its own scalar values (name and abbreviation, let's say). This configuration information could be expressed in Web.config using the following XML markup:

<ScottsSettings
     quoteOfTheDay="Hello, World!"
     yourAge="28">
   <favoriteStates>
      <add name="California" abbreviation="CA" />
      <add name="Missouri" abbreviation="MO" />
      <add name="Illinois" />
   </favoriteColors>
</ScottsSettings>

In Creating Custom Configuration Sections in Web.config we examined a technique for parsing the XML in custom configuration section that works in both ASP.NET 1.x and 2.0 applications. This required writing a bit of code. ASP.NET 2.0 applications, however, can utilize .NET 2.0's new configuration API, which makes creating custom configuration sections much easier. Read on to learn more!
Read More >

(Subscribe to this Article Series! )

The Health Monitoring system in ASP.NET 2.0 is designed to monitor the health of a running ASP.NET application in a production environment. It works by recording event information to a specified log source. The .NET 2.0 Framework includes a variety of built-in events that can be used by the Health Monitoring system, including events for monitoring application re-starts and stops, unhandled exceptions, and failed authentication attempts, among others. The .NET Framework also include support for logging these events to the Windows event log, to a Microsoft SQL Server database, via WMI, in an email, and to the ASP.NET page tracing system. As we saw in The Basics, when using the out-of-the-box events and log sources, the Health Monitoring system can be setup and configured entirely through Web.config without needing to write a single line of code!

In this article we will continue our exploration of the built-in events and log sources. In particular, we will look at the WebFailureAuditEvent event, which is raised when there is a security audit failure. We will also look at the SimpleMailWebEventProvider event provider, which, as its name implies, sends event information via email. Read on to learn more!
Read More >