There are several pre-defined events, providers, and rules inside the root web.config file in the same directory as machine.config (not to be confused with the web.config in your application). In the healthMonitoring section you will see several groupings for providers, rules, profiles, and event mappings. For right now, we’ll focus on providers, rules, and eventMappings. I’ll discuss how these play into logging events.

Providers (<providers>) essentially tell where the log information is going. For example, the provider named EventLogProvider maps to the EventLogWebEventProvider class. As you’d expect, this provides all those error events you see in your Event Viewer. Similarly, the SqlWebEventProvider allows you to log events to the built in ASP.NET database (ASPNETDB.mdf in your app_data folder or your own SQL Server instance configured using aspnet_regsql.exe). Web can define a custom provider in your application web.config file (or in the root if you want to apply it to all your sites) to, for example, generate and send an email to a recipient containing logged event information. The SimpleMailWebEventProvider does just this. We will define this provider and use this provider in our example below.

Rules (<rules>) dictate which event type will use a provider. For example, you can have application errors write to the SQL provider or generate an email using your the email provider mentioned above. The eventName attribute, when adding a rule, specifies the name of the web event to use. Basically, for each rule, you specify the eventName and the provider. Simple as that.

Event Mappings (<eventMappings>) are used for mapping event names to provider classes. In the root web.config, you will notice several pre-defined provider names associated with event classes (the type attribute). If you are creating your own web event class (we’ll cover this in a later post), you may create a name for it and give it a type (your new class). By default, you can leave these alone, as the web events shipped with the framework cover most cases.

There are several event mappings listed, but there are usually one or two which, I feel, would be used in most conditions. First, the All Errors event mapping (using WebBaseErrorEvent) is used for all compilation, runtime, and configuration errors. I have found this to be the most handy. The second is the Failure Audits event (using the WebFailureAuditEvent class), which raises a an application page is accessed using improper credentials. By default, ASP.NET uses the NETWORK SERVICE account to access the file system, the registry, any databases, etc. If incorrect permissions are set in the file system, or malicious code is attempting to access the file system, this event will be raised. One other potentially useful web event is the Infrastructure Error mapping. This web event is raised only for compilation and configuration errors. However, I personally find it less useful, as the All Errors web event covers this.

In this post, I will create a basic health monitoring event handler using the SimpleMailWebEventProvider class to generate an email whenever any runtime error is found on the site. The email, by default, will provide all the information I need to diagnose the error and make corrections. You may customize this email template, but that is another topic.

First, since we’re using an email provider, we need to configure SMTP settings in the web.config. The SimpleMailWebEventProvider class will use these settings for sending the email. Configure your SMTP settings as follows:

<configuration>
    ...
    <system.net>
        <mailSettings>
            <smtp deliveryMethod="Network">
                <network host="SERVER" userName="USERNAME" password="PASSWORD" />
             </smtp>
        </mailSettings>
    </system.net>
    ...
</configuration>

Once that is entered, we can begin enabling the health monitoring features and chose our provider and rules. Again, the purpose is to create an email for all site errors and send them to my email address.

<system.web>
    ...
    <healthMonitoring enabled="true">
        <providers>
            <add name="EmailSiteErrors" type="System.Web.Management.SimpleMailWebEventProvider" to="ryan@marriedgeek.com" from="noreply@marriedgeek.com" buffer="false"/>
        </providers>
        <rules>
            <add name="Email Errors" eventName="All Errors" provider="EmailSiteErrors"/>
        </rules>
    </healthMonitoring>
    ...
</system.web>

That’s pretty much it. The ease of configuration and separation of providers and rules makes it a breeze to configure monitoring for your website. If you chose to use a SQL event provider, your logs will be written in the  provider database configured in your maching.config’s connection string. You may even have both or as many provider/rule sets as you like.

This is an overview of how to get started with using health monitoring in ASP.NET. To read more about health monitoring, check out the following links:

• Health Monitoring in ASP.NET 2.0 (forums.asp.net)
• ASP.NET Health Monitoring Overview (msdn.microsoft.com)

A few entries ago we talked about custom server controls and mentioned how to structure a composite control to allow the ViewState to “pick up” on it’s post back content so that data isn’t re-binded with every call. It was a very basic composite control, but it showed how to add native WebControl objects to the Controls tree to create a basic layout without using a .ASCX design file. This type of control can be added to your app_code directory or manually compiled as an assembly and placed into your bin directory. The advantage of the latter is to feasibly add it to your Visual Studio toolbar by loading the assembly. This time, we’ll add a custom event to our control using a delegate for an event, as well as a custom event argument class to pass along with it.

We’ll take the code from last time, but add several things which are highlighted in green.

• A line to declare our event delegate variable and the delegate itself.
• A class which will be used for our arguments.
• A binded event for the button Click.
• A line in the button Click handler to invoke the event delegate.

using System;
using System.Web;
using System.Web.UI.WebControls;
using System.ComponentModel;

namespace RyanControls
{
    public class MyCompositeControl : CompositeControl
    {
        public MyCompositeControl() { }

        // Declare the Updating event of delegate type CustomControlUpdateHandler
        public event CustomControlUpdateHandler Updating;

        protected override void CreateChildControls()
        {
            TextBox txtMyData = new TextBox();
            DropDownList drpMyList = new DropDownList();
            Button btnUpdate = new Button() { Text = "Update!" };

            Controls.Add(drpMyList);
            Controls.Add(txtMyData);
            Controls.Add(btnUpdate);

            if (!Page.IsPostBack)
            {
                drpMyList.Items.Add(new ListItem("item 1"));
                drpMyList.Items.Add(new ListItem("item 2"));
                drpMyList.Items.Add(new ListItem("item 3"));
            }

            // Add a handler for the button click to launch the Updating event
            btnUpdate.Click += new EventHandler(FireEvent);
        }

        // The method that handles the Click event from the button
        // and triggers the Updating event by calling the delegate
        protected void FireEvent(Object s, EventArgs e)
        {
            Updating(s, new CustomControlUpdateEventArgs() { SomeData = "The control was updated!" });
        }
    }

    // Our custom event class that inherits EventArgs. You may use
    // EventArgs as the class if you don't have additional data to pass
    public class CustomControlUpdateEventArgs : EventArgs
    {
        public CustomControlUpdateEventArgs() { }
        public String SomeData;
    }

    // The delegate declaration (or template, as I call it) for the handler
    public delegate void CustomControlUpdateHandler(Object s, CustomControlUpdateEventArgs e);
}

There you have it. If you place this code into a .CS file inside your app_code directory, you’ll be able to include the control on your pages. If you compiled it into an assembly, toss it into your bin directory and feel free to add it to your toolbar in VS or VWD.

<asp:MyCompositeControl runat="server" ID="cntMyControl" OnUpdating="DisplayUpdate" />

By assigning an event handler for the Updating event (the page automatically prepends the “On” for “OnUpdating”) to call a method to handle the update, you can use data contained in the CustomControlUpdateEventArgs object. In this case, there’s only a public string called SomeData.

protected void DisplayUpdate(Object s, RyanControls.CustomControlUpdateEventArgs e)
{
    Response.Write(String.Format("<div>From the event handler: {0}</div>", e.SomeData));
}

When you run the code and click the button, the method will be invoked and the message displayed. Similarly, you can bind the handler programmatically by adding cntMyControl.Updating += new RyanControls.CustomControlUpdateHandler(DisplayUpdate) in your code-behind.

So again, while the code isn’t really useful, it shows how to create your own event handlers and custom argument class(es) for a composite server control. The point is to be able to create one or more event handlers, as well as combine those with one or more types of event argument classes. The fields of that particular argument class should be specific to that type of event and it is best not to use one custom event args class to satisfy many types of event argsuments, unless the data being passed into your hander functions generic enough to do so.

Happy coding!