If you are not familiar with the Elmah library, that’s okay, it’s a really basic concept. Simply put, it’s a lightweight easy to use library that integrates with ASP.NET that will capture all uncaught errors and store them for you in a central location. Go check it out:
While originally created for ASP.NET Web Forms, there is an MVC extension as well. Once configured you are ready to begin viewing your site errors recorded for you in real time by navigating to “elmah.axd”, or if you go extension-less the simple route of “~/elmah/” will work too. You end up seeing something like this:
You get a ton of metadata along with your error. But, I’ll let you look into that yourself.
After setting this up you’ll realize there are a number of config sections, connection strings (potentially), and app settings to add to the web.config file. Depending on what you plan to do with your web app, you may not care. However, if you are distributing your site into multiple environments, adding all this configuration really sucks, especially because 90% of it is one time setup that I will never, and should never change between environments. If you work hard enough at you can slim down your web.config file pretty small and avoid having things that never change in that file. If you’re still reading and saying who cares about how large the config file is, then consider your HttpModules as an example. These modules, as of .NET 4.0, you can register dynamically in pre application initialization, with a single short line of code that is type safe (since it won’t compile if it can’t find your module type), and realistically you’re not going to change anything about your http module between environments. AND for the final hooray, you won’t need to register that module in both system.web and system.webserver!!!!….. Okay, I hope that example gives you some ideas on just how much easier it can be to work with static configuration in code; will probably touch more on that in future dedicated post, but let’s assume from here we need to go config-less.
Okay, finally the meat. DO NOT put a single thing in your config file (watch those Nuget packages, depending which one you get it will auto configure or just provide core assembliesJ), but instead create a PreApplicationInitializationStartMethod in a static class and register the required HttpModules for elmah (depending on what you need: you may only require ErrorLogModule – but you can add ErrorFilterModule and the mail module too).
The above example I have my start method which registers the Elmah modules. If you’re not familiar with the PreApplicationStartMethod and the dynamic RegisterModule method, then check out this link (it will change your life):
The next key in this example is the “ServiceCenter.Current” assignment. ServiceCenter is a new addition to Elmah 1.2 that allows us to hook into the creation of the error log.
The static method “ElmahServiceProviderQueryHandler” is where you get to configure your log as you wish. In my example above I configure an XmlFileErrorLog at a particular folder location (~/Errrors/). If instead you want to instantiate a SqlErrorLog you can provide connection string as well as the Application Name.
Elmah should now be fully functional. You can do a quick test by navigating to an invalid URL on your site, and you should see an error show up. However, Elmah is additionally quite useful for logging custom exceptions and errors in your application. You can easily log to Elmah by retrieving the default log and passing it an exception like this:
Another simpler way to assume the context and log your exception looks like this (more standard approach):
You will notice that Elmah does require the HttpContext to create a log, as it will parse tons of additional details and contextual information out of the context to add to the exception – which is fantastic. However, you may find yourself in a tight bind, such as inside a WCF IIS Hosted service, or perhaps another thread from the web entry point where accessing the HttpContext is not an option! It does happen from time to time, especially in WCF Context, so you can log without that information by simply passing “null” when retrieving the log:
That should get you 100% setup and ready to use Elmah without any config, and with full programmatic examples!