ASP.NET integration guide

Add Bugsnag to your ASP.NET applications.

New to Bugsnag? Create an account and add Bugsnag to your app to automatically capture and report exceptions in production.

Installation

Manual Library Reference

  • Download the latest dlls and reference Bugsnag.dll, Bugsnag.AspNet.dll and Bugsnag.ConfigurationSection.dll in your project.

Compatibility

The ASP.NET library is compiled for .NET 3.5, 4.0, and 4.5.

Basic configuration

  • 1. Configure the Bugsnag integration inside your Web.config file
  • <configuration>
      <configSections>
        <section name="bugsnag"
                 type="Bugsnag.ConfigurationSection.Configuration, Bugsnag.ConfigurationSection" />
      </configSections>
      <bugsnag apiKey="your-api-key-goes-here" />
    </configuration>
    

  • 2. If you are using .NET 3.5 then you also need to add the Bugsnag Http module to your Web.config file in the following locations. This is done automatically if you are targeting .NET 4 or greater.
  • <configuration>
      <system.web>
        <httpModules>
          <add name="Bugsnag"
               type="Bugsnag.AspNet.HttpModule, Bugsnag.AspNet" />
        </httpModules>
      </system.web>
      <system.webServer>
        <modules>
          <remove name="Bugsnag" />
          <add name="Bugsnag"
               type="Bugsnag.AspNet.HttpModule, Bugsnag.AspNet" />
        </modules>
      </system.webServer>
    </configuration>
    

    Further configuration

    If you’d like to configure Bugsnag further, check out the configuration options reference.

    Reporting unhandled exceptions

    After completing installation and basic configuration, unhandled exceptions will be automatically reported to your Bugsnag dashboard.

    Reporting handled exceptions

    If you would like to send non-fatal exception to Bugsnag, you can pass any object that inherits from System.Exception to the Notify method

    try
    {
      throw new System.Exception("Error!");
    }
    catch (System.Exception ex)
    {
      Bugsnag.AspNet.Client.Current
        .Notify(ex);
    }
    

    Sending diagnostic data

    Automatically captured diagnostics

    As well as a full stacktrace for every exception, Bugsnag will automatically capture the following diagnostic data:

    • Request information, including IP address, headers, URL, HTTP method, and HTTP params
    • Hostname
    • Locale
    • OS Name
    • Timezone
    • Time

    Custom diagnostics

    It can often be helpful to attach application-specific diagnostic data to exception reports. This can be accomplished as follows:

    using System.Collections.Generic;
    
    // ...
    
    try
    {
      throw new System.Exception("Error!");
    }
    catch (System.Exception ex)
    {
        Bugsnag.AspNet.Client.Current.Notify(ex, (report) => {
            report.Event.Metadata.Add("account", new Dictionary<string, string> {
                { "company", "Acme Co." },
                { "id", "4425" },
            });
        });
    }
    

    Identifying users

    In order to correlate errors with customer reports, or to see a list of users who experienced each error, it is helpful to capture and display user information on your Bugsnag dashboard.

    You can set this information using a callback as follows:

    Bugsnag.AspNet.Client.Current.BeforeNotify(report =>
    {
        report.Event.User = new Bugsnag.Payload.User
        {
            Id = "45556",
            Name = "Bob Smith",
            Email = "bob@example.com"
        };
    });
    

    For more information, see Customizing error reports.

    Logging breadcrumbs

    In order to understand what happened in your application before each error, it can be helpful to leave short log statements that we call breadcrumbs. The last 25 breadcrumbs are attached to an error report to help diagnose what events lead to the error. Captured breadcrumbs are shown on your Bugsnag dashboard as a part of the error report.

    You can leave manual breadcrumbs via the Breadcrumbs property on the client object.

    Bugsnag.AspNet.Client.Current.Breadcrumbs
      .Leave("Something happened!");
    

    You can optionally attach a type and metadata to a breadcrumb for additional context into the state of the application when the breadcrumb was captured.

    Bugsnag.AspNet.Client.Current.Breadcrumbs
      .Leave("Something happened!", Bugsnag.BreadcrumbType.Navigation, null);
    

    With additional diagnostic metadata:

    var metadata = new Dictionary<string, string> { { "foo", "bar" } }
    Bugsnag.AspNet.Client.Current.Breadcrumbs
      .Leave("Something happened!", Bugsnag.BreadcrumbType.State, metadata);
    

    Session tracking

    Bugsnag can track the number of “sessions” that happen in your application. This enables Bugsnag to provide and compare stability scores between releases to help you understand the quality of your releases.

    This functionality is disabled by default and can be controlled through the AutoCaptureSessions configuration value:

    configuration.AutoCaptureSessions = true;
    

    Using this option, Bugsnag will report a session each time a request is received.

    If you want control over what is deemed a session, rather than using the AutoCaptureSessions option, you can call the following when appropriate for your application.

    Bugsnag.AspNet.Client.Current.SessionTracking.CreateSession();
    

    Symbolication guide

    Stacktraces from .NET platforms will be automatically populated with line numbers and file names for dlls that the runtime can find symbols for. This usually means that you should deploy the .pdb files alongside your dlls so that Bugsnag is able to retrieve this information.

    Next steps