NuGet #2: Elmah – Error Logging Modules and Handlers for ASP.NET
Well, that’s the real title of the package. It’s a really cool package in my opinion. Where you had to configure it before (well, 3 lines of web.config), it now automatically installs through NuGet. Just one click and you have your error logging installed.
You often don’t know what errors happen when people visit your website/application. People just got a yellow screen of death and didn’t know what to do with it and hit reload hoping the screens dissapears, which, in many cases, won’t dissapear of course. But people don’t very often report it, but you would probably want to know what went wrong. This is where Elmah comes in.
All credits go to Atif Aziz (@raboof on Twitter) for creating this package. It has been around for a long time, even before I even started my professional career and just recently discovered it.
http://www.hanselman.com/blog/ELMAHErrorLoggingModulesAndHandlersForASPNETAndMVCToo.aspx
What does Elmah do?
And I quote (why type it yourself, if you can just copy-paste it?)
- Logging of nearly all unhandled exceptions.
- A web page to remotely view the entire log of recoded exceptions.
- A web page to remotely view the full details of any one logged exception, including colored stack traces.
- In many cases, you can review the original yellow screen of death that ASP.NET generated for a given exception, even with customErrorsmode turned off.
- An e-mail notification of each error at the time it occurs.
- An RSS feed of the last 15 errors from the log.
And what does it stand for?
Error Logging Modules and Handlers
Let’s implement it
What’s there to implement? There’s really nothing to it. Ok, here goes!
Make a new ASP.NET MVC application (or WebForms, whatever you prefer). You don’t have to care about a web template for this demo. Just click OK.
Now add Elmah to you application through NuGet.
PM> Install-Package Elmah
Well, we’re done. But not until we’ve generated an error. Let’s build the application and view the webpage. Now navigate to http://localhost:[port]/somepagethatdoesntexist, so we get a 404 error.
We wouldn’t know that this error has occured. Do we have a dead link? Well, let’s find out. Navigate to http://localhost:[port]/elmah.axd and you enter the Error log for the local machine.
Hey, did you know we are also missing a favicon?!?! That’s probably a critical error for the marketing department. Let’s inspect it. You can just click on details behind the error and you get your error stack and also the server variables at the moment of the call. Isn’t that cool? Well, I like it. Looking at the error we have to put a favicon.ico in the root of our website. That has to be designed of course, and then tested by the marketing department. Probably be solved in a few months then!
That was quick, wasn’t it? I think it’s very usefull if you are developing a website and want to know if errors are occuring, or even for testing purposes. The testers don’t really have to log every detail for an error that occurs. You can find the details yourself.
Of course we now have the Microsoft Test Suite including intellitrace. Will cost you something, but that’s really cool too. Let’s just stick to this for now and use the Microsoft Test Suite for the really big projects.
