We all do our best to develop robust applications with efficient code with the proper logic to handle exceptions, but computers and users can be unpredictable, and unhandled exceptions can creep into production. The key is to recognize and address these problems as soon as possible, but their random nature does not make it easy. Thankfully, the Error Logging Modules and Handlers (ELMAH) can watch your ASP.NET applications when you are not available.
What is ELMAH?
The project site describes ELMAH as “an application-wide error logging facility,” but this may not impress you, as there are plenty of ways to properly deal with exceptions. The key feature of ELMAH is it requires no coding or recoding of your application. That’s right — it can be added to an existing ASP.NET application on the fly. Once ELMAH is in place, it keeps a log of all unhandled exceptions and details; this log can be used to determine the root cause and avoid future occurrences.
ELMAH is also one of the best open source projects for the ASP.NET platform. Since discovering ELMAH, I use it on all of my applications.
ELMAH is freely available in a zip file on the project site. Installation is as simple as extracting the contents of the zip file; this includes a base directory that contains the license, readme, and a demo command file to kick off the demo. In addition, there is a samples directory for getting a feel for using it, along with a bin directory for DLLs, a db directory with setup files for the various backend options, and the tools directory, which contains the Cassini Web server used by the product. The current product release utilizes .NET 2.0.
Once it’s installed, a quick click of the demo.cmd file gives you a quick look at how the product works. It takes you to a page where you can trigger exceptions and provides a link to the ELMAH Web service, which has an overview of exceptions (it all utilizes the Cassini Web server). Figure A shows the default presentation of the ELMAH Web server.
The ELMAH Web service listing (Click the image to enlarge.)
You can drill down into an exception from the Details link on the page in Figure A. Figure B shows an example of drilling down into a Web application unhandled exception. It provides a stack trace at the top of the page with a list of all HTTP server variables listed at the bottom of the page.
The details of an unhandled exception (Click the image to enlarge.)
In addition to viewing exceptions in a browser, you can download the details in a comma-delimited csv file (via the Download Log link in Figure A) or as an RSS feed of the last 15 exceptions (RSS Digest link in Figure A). Exception details are viewed as HTML in Figure B, but there are links for viewing them as XML or JSON. While the demo application tracks exceptions in a text file, you may choose to store exception details in a backend database. The product supports Microsoft Access, SQL Server, MySQL, PostgreSQL, and Oracle. Finally, you can choose to be emailed each time an exception occurs.
Watching your application
In order to put ELMAH to use in your application, you need to make additions to your application’s web.config file and drop the elmah.dll file in your application’s bin directory. Once that is complete, you can view all unhandled exceptions for your application using the application’s base URL plus elmah.axd (for example: http:/localhost/virtualdirectory/elmah.axd). The installation file contains a sample web.config in the samples directory.
For my basic setup to log to a text file, I used the following elements:
- Elmah section in the configSections element. I added the following two for logging:
<sectionGroup name="elmah"> <section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah"/> <section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah" /> </sectionGroup>
- Add the necessary httpHandlers section:
<httpHandlers> <add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" /> </httpHandlers>
- Add the necessary webServer elements:
<system.webServer> <validation validateIntegratedModeConfiguration="false" /> <modules> <add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah" preCondition="managedHandler" /> </modules> <handlers> <add name="Elmah" path="elmah.axd" verb="POST,GET,HEAD" type="Elmah.ErrorLogPageFactory, Elmah" preCondition="integratedMode" /> </handlers> </system.webServer>
- Add elements for the ELMAH Web service:
<location path="elmah.axd"> <system.web> <authorization> <deny users="?"/> </authorization> </system.web> </location>
Your setup may include additional elements if you want to use email or Twitter or filter the exceptions. In addition, there are more web.config elements for using a database backend to store exception details. The sample web.config includes all of these sections with plenty of comments that make it simple. You may want to secure access to the ELMAH Web service, which can be accomplished in the last bullet above (authorization element).
Dealing with issues
I have had great success using ELMAH, though in a couple instances, computer security settings have caused major headaches; this is usually the result of IIS security settings, and I use the MetaAcl tool to grant the IIS user (for the application) the necessary rights. The ELMAH Google groups can provide plenty of direction when faced with such issues.
Why not use EMLAH?
ELMAH is so easy to use and configure that I cannot understand why a developer wouldn’t use it. It’s also a godsend for support personnel, who can quickly recover a production application from an unhandled exception while providing details of the exception for developers to resolve the problem, thus avoiding similar issues in the future.
Some developers say ELMAH can be used to completely replace all exception handling code, but I don’t go that far with it. I think ELMAH is a great compliment to good code.
Keep your engineering skills up to date by signing up for TechRepublic’s free Software Engineer newsletter, delivered each Tuesday. Automatically subscribe today!