Logging ASP.NET MVC Errors Using ELMAH

mistake-1194670_640When beta testing an application it’s important that you receive high quality error reports. We’ve all had users send reports such as:

  • “It’s broken.”
  • “My screen looks funny.”
  • “I can’t log in.”

Far better to have the application itself report any errors. That provides actionable data, including:

  • type of error
  • location of error
  • stack trace
  • browser vendor/version

One of the benefits of developing web applications is that we don’t have to pull these reports from client machines—the code is (mostly) running on our servers. Of course, we have to write all that extra code to provide this error reporting.

Or do we? Not if we’re using ASP.NET.

ELMAH

ELMAH is an application-wide error logging facility. You can add it to an existing application without having to write a single line of code. Let’s see how we can add error logging to an ASP.NET MVC application.

There’s a NuGet package that is designed specifically to integrate ELMAH with ASP.NET MVC applications. Install it via the Package Manager Console.

Install-Package Elmah.MVC

That’s it. We’re done. Pretty painless I’m sure you’ll agree. So, let’s take it for a spin. Create an action method that throws an exception.

public ActionResult Index()
{
    throw new Exception("Testing our application-wide error logging");
}

Run it and experience the “yellow screen of death”. Now, navigate to the “elmah” resource in your application.

http://localhost:60146/elmah

You should see a list containing one error.

ELMAH error log

The entry displays the exception type, the message we supplied when throwing the exception and the time that the exception occurred.

If we click on the Details... link we get all sorts of information that would be invaluable in tracking down the error, including

  • stack trace
  • HTTP headers
  • browser
  • request parameters

Error logging for free. What’s not to love?

Configuring ELMAH

ELMAH has a number of configuration options that you will probably want to use. When we installed the package it added an <elmah></elmah> section to the application’s Web.config file. We can control ELMAH’s behavior by adding options in this section.

First, we really don’t want an error log accessible to the public. As well as showing how bug-ridden our code is it’s a potential security hole. We can restrict access so that the log can only be viewed on the local web server.

<elmah>
  <security allowRemoteAccess="false" />
<elmah>

Second, by default, ELMAH holds the log in memory. This means we’ll lose it if the application is restarted. We can configure ELMAH to use SQL Server as a persistent store.

<connectionStrings>
  <add name="ElmahLog" 
      connectionString="..." 
      providerName="System.Data.SqlClient" />    
</connectionStrings>

<elmah>
  <errorLog type="Elmah.SqlErrorLog, Elmah" 
            connectionStringName="ElmahLog" />
<elmah>

There is a DDL script available for creating the database.

Finally, you may wish to have any errors e-mailed to you. This kind of alerting approach means you can fix problems as they occur—leaving users oblivious to the fact there even was an error.

You can send ELMAH alerts via any SMTP server. I use the excellent Mandrill service.

<elmah>
    <errorMail from="alerts@company.com" 
               to="someone@company.com" 
               subject="Application error" 
               async="true" 
               smtpServer="smtp.mandrillapp.com" 
               smtpPort="587" 
               userName="someone@company.com" 
               password="..." />
<elmah>

This article has described how easy it is to add error logging to your ASP.NET MVC applications. There’s no excuse not to have it.

If you are interested in learning more about ASP.NET MVC have a look at Learning Tree’s Building Web Applications with ASP.NET MVC course.

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.