Skip to content
ErrorDock

For .NET

ErrorDock for .NET.

ErrorDock provides error monitoring, product analytics and locally evaluated feature flags for .NET applications, with a package for each kind of host: ErrorDock.AspNetCore for ASP.NET Core, ErrorDock.Extensions.Logging for worker and console apps on the generic host, ErrorDock.WinForms and ErrorDock.Wpf for the desktop, and ErrorDock.Core for everything else. Core targets netstandard2.0 and net8.0, so it runs on .NET Framework 4.7.2 and .NET 8, 9 and 10. Performance comes from OpenTelemetry.

A package for each kind of host

Install the package that matches the application, register it, and errors, product events and feature flags all flow from the same configuration and the same key. There is no second SDK for analytics, no third for flags, and no separate agent process. Request and query timing come from OpenTelemetry, forwarded to ErrorDock as OTLP/HTTP JSON through an OpenTelemetry Collector, and the spans arrive in the same project.

  • ErrorDock.AspNetCore: ASP.NET Core, including Blazor Server
  • ErrorDock.Extensions.Logging: an ILogger provider for worker and console apps
  • ErrorDock.WinForms and ErrorDock.Wpf: Windows desktop applications
  • ErrorDock.Core: console tools, plug-ins, Avalonia, MAUI and anything else

Feature flags evaluated in your process

.NET is the SDK that carries a flag client. A flag check reads an immutable snapshot already in memory — no network call, no lock — and keeps answering when ErrorDock is unreachable, because a restart during an outage loads the snapshot from disk before the host serves traffic.

  • IsEnabled returns in about a quarter of a microsecond
  • Deterministic bucketing, so a user stays in their cohort
  • A kill switch that beats every explicit target
  • Your own default value when there is no configuration at all

Desktop, not just the web server

ErrorDock.WinForms and ErrorDock.Wpf hook the dispatcher and thread exception handlers of a desktop application, so an unhandled exception in a client arrives as an issue in the same project as the API it talks to. Both target .NET Framework 4.7.2 as well as .NET 8, because that is where the applications actually are.

Stack traces that resolve to your source

With portable PDBs published or embedded, the stack trace the runtime produces carries file and line, and the SDK marks application frames separately from framework and package frames. Nothing is symbolicated on the server. Async stack traces are reassembled rather than shown as the state-machine frames the runtime actually produces.

Built for the Microsoft stack

Dependency injection, IOptions configuration, ILogger integration and hosted service support are first-class rather than adapted from a JavaScript-first design. Query timing is left to the instrumentation built for it: Entity Framework Core's OpenTelemetry instrumentation produces the query spans.

  • Registered through the built-in DI container
  • Configured through IOptions and appsettings
  • Enriches ILogger scopes rather than replacing them
  • EF Core query spans through OpenTelemetry

Frequently asked questions

Which .NET versions does the SDK support?
ErrorDock.Core targets netstandard2.0 and net8.0, so it runs on .NET Framework 4.7.2 and on .NET 8, 9 and 10.
Does it work with Blazor?
Blazor Server runs on ASP.NET Core, so ErrorDock.AspNetCore covers it. Blazor WebAssembly is not a documented target.
What about desktop applications?
ErrorDock.WinForms and ErrorDock.Wpf hook the thread and dispatcher exception events respectively, and both target .NET Framework 4.7.2 alongside .NET 8. Neither changes whether an exception is treated as handled — reporting a crash must not alter whether the application crashes.

Related

Bring your application into focus.

Tell us about your stack. We will help define the right beta setup for your first project.