Sentry 1.0.0

Below you will find a basic introduction to the SDK and its API.

For more details, please: refer to the SDK docs and API docs For API docs, check out:

Main features

• Automatic Captures global unhandled exceptions (AppDomain)
• Scope management
• Duplicate events automatically dropped
• Events from the same exception automatically dropped
• Web proxy support
• HttpClient/HttpClientHandler configuration callback
• Compress request body
• Event sampling opt-in
• Event flooding protection (429 retry-after and internal bound queue)
• DSN discovered via environment variable
• Release (version) reported automatically
• CLS Compliant
• Strong named
• BeforeSend and BeforeBreadcrumb callbacks
• Event and Exception processors
• SourceLink (including PDB in nuget package)
• Device OS info sent
• Device Runtime info sent
• Enable SDK debug mode (opt-in)
• Attach stack trace for captured messages (opt-in)
• Tested on Windows, Linux and macOS
• Tested on .NET Core, .NET Framework and Mono

Basics

Initialize the SDK:

void Main() 
{
    using (SentrySdk.Init("dsn"))
    {
        // App code
    }
}

The SDK by default will watch for unhandled exceptions in your app. If the DSN is not explicitly passed by parameter to Init, the SDK will try to locate it via environment variable SENTRY_DSN.

To configure advanced settings, for example a proxy server:

void Main() 
{
    using (SentrySdk.Init(o =>
    {
        o.Dsn = new Dsn("dsn");
        o.Proxy = new WebProxy("https://localhost:3128");
    }))
    {
        // App code
    }
}

Capture an exception:

try
{
    throw null;
}
catch (Exception e)
{
    SentrySdk.CaptureException(e);
}

Capture a message:

SentrySdk.CaptureMessage("this just happened");

Internals/Testability

It's often the case we don't want to couple our code with static class like SentrySdk, especially to allow our code to be testable. If that's your case, you can use 2 abstractions:

• ISentryClient
• IHub

The ISentryClient is responsible to queueing the event to be sent to Sentry and abstracting away the internal transport. The IHub on the other hand, holds a client and the current scope. It in fact also implements ISentryClient and is able to dispatch calls to the right client depending on the current scope.

In order to allow different events hold different contextual data, you need to know in which scope you are in. That's the job of the Hub. It holds the scope management as well as a client.

If all you are doing is sending events, without modification/access to the current scope, then you depend on ISentryClient. If on the other hand you would like to have access to the current scope by configuring it or binding a different client to it, etc. You'd depend on IHub.

An example using IHub for testability is SentryLogger and its unit tests SentryLoggerTests.
SentryLogger depends on IHub because it does modify the scope (through AddBreadcrumb). In case it only sent events, it should instead depend on ISentryClient

Compatibility

The packages target .NET Standard 2.0. That means it is compatible with the following versions or newer:

• .NET Framework 4.6.1 (4.7.2 advised)
• .NET Core 2.0
• Mono 5.4
• Xamarin.Android 8.0
• Xamarin.Mac 3.8
• Xamarin.iOS 10.14
• Universal Windows Platform 10.0.16299

Of those, we've tested (we run our unit/integration tests) against:

• .NET Framework 4.7.2 on Windows
• Mono 5.12 macOS and Linux (Travis-CI)
• .NET Core 2.0 Windows, macOS and Linux
• .NET Core 2.1 Windows, macOS and Linux