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
- ErrorDock for ASP.NET Core. Add ErrorDock to an ASP.NET Core application in two lines for exception capture with request context, and export OpenTelemetry spans for endpoint latency percentiles and Entity Framework Core queries.
- Find the failure. Keep the context. Group exceptions into issues, inspect stack traces and breadcrumbs, and understand which users and releases are affected.
- Release with a little more control. Configure flags by environment, roll out gradually and compare cohort health to understand how a change behaves in use.
- .NET error monitoring. How exception handling, logging and error monitoring fit together in .NET, and what to capture from an ASP.NET Core application.
Bring your application into focus.
Tell us about your stack. We will help define the right beta setup for your first project.