Let me start by saying that I’ve only just started using Exceptioneer.  This is my first web application that I’m trying to use it for but it’s seriously impressive so far.  For those that haven’t used it, Exceptioneer is a web service that allows you to monitor, track, and pro-actively resolve issues that arise within web applications.  With Exceptioneer, you add a reference to a DLL, update some config files, and all untrapped errors are recorded for analysis within their website.  Moreover you can even get email/twitter updates of new issues.

On their feedback, though, the most requested feature is to ignore localhost.  This makes sense as you rarely need to track exception information whilst you’re actively developing/debugging the software.  This is a planned release but I decided to come up with an alternative.

Before we go any further: this will only work with ASP.NET 4.0 using Visual Studio 2010.

As many people will probably know, Visual Studio 2010 – or ASP.NET 4.0, really – added support for Web.Config transformations.  I’m not going to go into too much detail but it allows you to customise the Web.Config file that’s generated, depending upon your targeted environment.

Noting this, I decided that this was an excellent way for me to -proverbially – kill two birds with one stone.

Firstly, add a reference to the Exceptioneer.WebClient DLL file. Next, the notes within Exceptioneer ask you to modify the Web.Config file directly.  Instead of that, we’re going to alter the Web.Release.Config file.

Upon opening the file, you’ll notice it’s very sparse.  This is because this file contains information on how to transform the main Web.Config file when targeting the release environment, so most of the meat sits within the main file.

Simply update this release file with the following (remembering to change the ApiKey and ApplicationName attributes on the “Exceptioneer” node):

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <configSections>
    <section name="Exceptioneer"
            type="Exceptioneer.WebClient.ClientModuleConfiguration, Exceptioneer.WebClient"
            requirePermission="true"
              xdt:Transform="Insert"
       />
  </configSections>
  <!-- This is where you get to specify your API Key and Application Name -->
  <Exceptioneer ApiKey="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" ApplicationName="My Application" xdt:Transform="Insert" />
  <system.web>
    <httpHandlers>
      <add name="Exceptioneer"
       type="Exceptioneer.WebClient.ClientModule, Exceptioneer.WebClient"
            xdt:Transform="Insert"
        />
    </httpHandlers>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
  </system.web>
  <system.webServer>
    <modules>
      <add name="Exceptioneer"
              preCondition="managedHandler"
              type="Exceptioneer.WebClient.ClientModule, Exceptioneer.WebClient"
            xdt:Transform="Insert"
        />
    </modules>
  </system.webServer>
</configuration>

And that’s it.  If you deploy the application whilst targeting the Release environment, your system should hook into Exceptioneer.  In other environments, e.g. Debug, the system won’t hook into Exceptioneer – you’re free to break everything locally without spamming Exceptioneer with exceptions (and yourself with alerts!).