Cool, I just learnt something. The [HandleError] attribute is registered globally when we created a new project. That’s going to make the rest of this blog post easier…

Logging Exceptions

In our development environment, when these exceptions are thrown they appear in the eventlog. But in production, they don’t get put into the eventlog. We need to log them somewhere!
There’s a bucketload of ways to log in ASP.NET – log4net, ELMAH, etc. But I decided I wanted to use one that comes built into ASP.NET – health monitoring.

But that’s not enough. For some reason, the ASP.NET MVC [HandleError] attribute (registered globally in Global.ascx.cs, remember) doesn’t invoke the health monitoring features. But thanks to a helpful post by Andrew Wilinski, we can create our own HandleError attribute which will. Create a new class called HandleErrorHm.cs:

Big success!! Our exceptions appear in the eventlog on our production web server.

Logging to a SQL database

Since I’m already using ASP.NET authentication I already have an aspnet_WebEvent_Events table. So if I follow the rest of the 4GuysfromRolla post, I can set it up to log to my existing application database:

Note that in our dev environment it will still show the YSOD for 404s, but in production our users will get redirected correctly.
One final note: if you follow these steps, 404s are NOT logged by health monitoring.

After you plug in the Appfail reporting module (via nuget) your application begins reporting all unhandled exceptions to Appfail’s cloud service. You can then log into Appfail’s dashboard to view analytics on your application’s failures. You can register to receive email/text message notifications for particularly important failures.

It also has an overlay that you can plug in to your web site with a <script /> tag, which shows you failure information about each page as your browse your site.