Rollbar.NET Notifier SDK

A .NET Rollbar Client/Notifier SDK that can be used in any application built on the following .NET versions: .NET Core 2.0+, .NET Standard 2.0+, .NET Full Framework 4.5+, Mono, Xamarin, and, in general, any implementation of the .NET Standard 2.0+. It simplifies building data payloads based on exception data, tracing data, informational messages and telemetry data and sends the payloads to the Rollbar API for remote monitoring and analysis of the hosting application's behavior and health.

It also includes a collection of adapters and helpers for many .NET application frameworks as well as a collection of Rollbar.NET plug-ins into most popular .NET logging and exception handling libraries/frameworks, like:

• Serilog
• log4net
• NLog
• Microsoft Enterprise Library's Exception Handling block
• etc.
• as well as RollbarTraceListener and ASP.NET Core Rollbar middleware.

These plug-ins simplify integration of the Rollbar.NET Notifier into codebases that are already using any of these libraries/frameworks using the libraries' native extensions mechanisms.

NEW MAJOR RELEASE (v5) ANNOUNCEMENT

A new major release v5 of the SDK is available. The primary new feature of this release is the support of Blazor Client/Webassembly/WASM.

For detailed instructions see our v5 specific documentation.

Codebase status (code quality and CI build)

Available as NuGet packages

• Rollbar (the core)....................
• Rollbar.Deploys.......................
• Rollbar.NetPlatformExtensions.........
• Rollbar.NetCore.AspNet................
• Rollbar.Net.AspNet....................
• Rollbar.Net.AspNet.Mvc................
• Rollbar.Net.AspNet.WebApi.............
• Rollbar.PlugIns.Log4net...............
• Rollbar.PlugIns.MSEnterpriseLibrary...
• Rollbar.PlugIns.NLog..................
• Rollbar.PlugIns.Serilog...............

Install

Using Nuget Package Manager:

Install-Package Rollbar

Blocking vs Non-Blocking Use

The SDK is designed to have as little impact on the hosting system or application as possible. It takes an async "fire and forget" approach to logging. Normally, you want to use fully asynchronous logging, since it has virtually no instrumentational overhead on your application execution performance at runtime (especially when running on a multi-core/multi-processor system).

In v1.x.x versions of the SDK, the asynchronous logging calls were still performing some of their data processing functions (like packaging the data objects to log into a proper Rollbar Payload DTO instance) on the calling thread before asynchronously placing the payloads into a transmission queue. Hence, the duration of the logging method calls was proportional to the size and complexity of the data object to package and log.

In v2.x.x versions of the SDK, we moved the packaging of the data-to-log one level deeper and now it is handled in a context of a worker thread that is responsible for packaging of a proper payload DTO and queuing it for transmission to the Rollbar API Server. As the result, the logging method calls are extremely quick now (under 20 microseconds) regardless of complexity and size of the data-to-log. All the methods now return a Task instance (instead of an ILogger instance as in v1.x.x) that could be either ignored in true "fire-and-forget" logging scenarios or could be waited (or awaited) to complete packaging and queuing of the payloads in some scenarios.

While it was a nice flexible and easy to use solution from API point of view, the tasks did not perform well (as we learned it the hard way) under EXTREMELY high AND sustained rate of load. So, in v3.x.x, we went away from the Tasks and removed IAsynLogger all together. We are now back to having only ILogger and we have a substitute for the eliminated Tasks in the form of IRollbarPackage. Think of the IRollbarPackage as a basis for implementing arbitrary data packaging strategies with explicit flag (named as MustApplySynchronously) that signifies need to apply the packaging (steps 1 and 2) on the calling thread before returning from a logging method. We also provide with abstract base classes like RollbarPackageBase and RollbarPackageDecoratorBase for implementing custom packaging strategies and their decorators. We used these abstraction to implement our own collection of packagers and their decorators. All of them are available to the SDK users as well. In addition to helping us in getting away from the Tasks usage, these new abstractions allow for very flexible and powerful ways to bundle a lot specific types of data into a single payload as needed while encapsulating and reusing the packaging rules of any custom type.
In v3.x.x, you can either throw into a logging method a data object to log (exactly the way it was in v2) or you can wrap in an ObjectPackage while setting the MustApplySynchronously flag if you want the logger to behave the way IAsyncLogger used to when you had to block-wait on its Task to complete.

However, in some specific situations (such as while logging right before exiting an application), you may want to use a logger fully synchronously so that the application does not quit before the logging completes (including subsequent delivery of the corresponding payload to the Rollbar API).

That is why every instance of the Rollbar logger (implementing ILogger interface) defines the AsBlockingLogger(TimeSpan timeout) method that returns a fully synchronous implementation of the ILogger interface. This approach allows for easier code refactoring when switching between asynchronous and synchronous uses of the logger.

Therefore, this call will perform the quickest possible asynchronous l