Exceptionless.Net: error reporting clients for .NET applications

What the clients actually do

The name has a definition attached, which is worth repeating because it tells you the intent. The definition of the word exceptionless is to be without exception, and Exceptionless provides real-time .NET error reporting for ASP.NET, Web API, WebForms, WPF, console and MVC apps. It organizes the gathered information into simple actionable data that will help your app become exceptionless.

So the split is between the client libraries in this repository and the service they talk to. The client is what you reference from your application, it hooks into the framework's error handling, and it sends events out. The service is what receives them, groups them, and turns a stream of exceptions into something a developer can act on. The readme is careful to point at the Exceptionless documentation for how to use it, which is where the configuration of what gets collected lives.

The framework list in that sentence is the real scope of the project, and it spans a decade of .NET. ASP.NET and ASP.NET Core, the older ASP.NET Web Forms and Web API, WPF on the desktop, console applications and MVC. The repository topics make the same point, listing asp-net, asp-net-core, crash-reporting, error-reporting, exception-handler, exceptionfilter, logging-library, unhandled-exceptions, wcf, webforms, winforms and wpf.

That breadth is the reason the project exists as a set of clients rather than a single package. A tool that only handles ASP.NET Core would be a much smaller project, but it would not serve the team that still has Web Forms in production.

The samples are the best documentation of the coverage

The samples directory lists thirteen sample applications, and the list is the clearest evidence of what the clients support.

There is Exceptionless.SampleAspNetCore, Exceptionless.SampleBlazorWebAssemblyApp, Exceptionless.SampleConsole, Exceptionless.SampleHosting, Exceptionless.SampleLambda, Exceptionless.SampleLambdaAspNetCore, Exceptionless.SampleMaui, Exceptionless.SampleMvc, Exceptionless.SampleWcf, Exceptionless.SampleWeb, Exceptionless.SampleWebApi, Exceptionless.SampleWindows and Exceptionless.SampleWpf.

Read as a set, that covers the hosting models rather than repeating the same thing. A console application and a Windows application are the simplest possible hosts for an unhandled exception handler. MVC, Web API and Web cover the classic ASP.NET stack, AspNetCore covers the modern one, Hosting and Lambda cover the generic host and the serverless model, Blazor WebAssembly covers the browser, MAUI covers the cross-platform app framework, and WCF and WPF cover the older communication and desktop stacks.

Blazor WebAssembly and Lambda are the two that stand out as deliberate design decisions rather than leftovers. A WebAssembly application runs in the browser, so there is no server-side process to report from, and a Lambda function has a very short lifetime, so an error needs to be reported before the runtime disappears. Both are cases where a conventional logging library that writes to disk is the wrong tool.

The samples are also how a developer decides whether the client fits. The readme tells you to select Exceptionless.SampleConsole as the startup project and press F5 to start the console, which is the fastest possible way to see the client work before you wire it into anything real.

Building on three platforms, and three solution files

The build setup is where the framework breadth becomes concrete work, and the readme handles it in two variants.

There are three solution files at the root, Exceptionless.Net.slnx, Exceptionless.Net.Windows.slnx and Exceptionless.Net.NonWindows.slnx, and the split is not cosmetic. A client package for a Windows-only framework cannot be built on macOS, so the full solution contains projects that will not build everywhere, and the platform-specific solutions are the ones that will.

There is also a global.json pinning the SDK, a .devcontainer directory for a reproducible development environment, and separate CI workflows for Windows, macOS and Linux, which is the same three-way split on the build server.

The Windows route is described as preferred so all platforms can be built and editor design surfaces are available. It needs Visual Studio 2022, the .NET 10 SDK with Visual Studio tooling, and the .NET Framework 4.7.2 Developer Pack, that last one for the older targets. Then you open the solution, select the console sample as the startup project and press F5.

The Visual Studio Code route is for building on macOS or Linux, with the trade-off stated plainly: you lose some of the rich design surfaces and the ability to build Windows specific packages. It needs Visual Studio Code and the .NET 10 SDK, and then you open the cloned folder and run the console sample with F5.

The modern tooling is visible in the choices. The solution file uses the .slnx format, which is the newer XML based solution format, and the target framework list in the readme includes .NET Framework 4.7.2 alongside .NET 10, which tells you the library still supports the older runtime and is not simply a .NET 10 project.

Consuming the clients, and what the licence covers

For anyone not building the repository itself, the readme is direct about where to go. All of the.NET clients can be installed via the NuGet package manager, and the development section carries an explicit warning that it is for development purposes only, and that if you are trying to use the Exceptionless.NET libraries you should get them from NuGet.

The NuGet profile linked is the vendor's own, and the readme points at it with a flag to show all packages, which is worth noting because the profile is not a single package. A.NET client that covers ASP.NET Core, Web Forms, WPF, WCF and console applications is several packages, and the differences in what each one includes are exactly the kind of thing a package list makes visible.

The licence is the point that needs a caveat. The project is recorded as having a custom licence that GitHub cannot classify, with a LICENSE.txt file in the repository, and the readme does not summarise the terms the way the Apache and MIT projects usually do. That means the actual grant has to be read in the file, and a team that is standardising on a known licence will want to do that before shipping it in a product.

The recent releases are v6.2.0 from 2026-06-16, v6.1.0 from 2025-04-08 and v6.0.4 from 2024-03-29, and the last push was on 2026-10-22, so the 6.x line is still receiving work. The homepage is exceptionless.com, the project has a Discord for support, and there is an in-app support route plus the option to open an issue on the repository, which the readme offers as the two ways to get help.

What to check before you send production exceptions anywhere

There is one question this repository does not answer, and it is the one an engineering lead will ask first: what happens to the data once it leaves your process.

Exception reporting by its nature sends application internals outward. A stack trace names your methods, your namespaces and your file structure. The request context attached to a web exception can carry route templates, query strings, form fields and sometimes headers. A crash in a console application can carry whatever was on the stack when it happened, including argument values. None of that is usually sensitive in a useful way, but some of it occasionally is, and the team that owns the data has to decide rather than discover.

That is a configuration question, and the readme points at the Exceptionless documentation for how to use the clients, which is where the inclusion and exclusion options are described. The thing to do before deploying is to run the console sample against a private project and read the payloads it sends, rather than reading the documentation and assuming.

The second question is where the data goes and who can see it. The service is operated by the Exceptionless vendor, and the documentation describes Exceptionless as a service you can point your clients at, with a self-hosted option alongside it. A team with a compliance requirement will want to know whether the self-hosted option satisfies it, and that is a question for the service documentation rather than for this client repository.

The third is the operational one. Sending events is a network call on a path that is usually already in trouble, because a service that is throwing exceptions is often also slow or partially down. A client that blocks the request thread while it tries to report the error turns a degraded application into a hung one. Whether the Exceptionless clients buffer, batch and shed load under those conditions is exactly the kind of detail to look for in the documentation before you rely on the reporting to be available during an incident.

None of this makes the project a poor choice. It makes it a choice with a data flow, and the flow is worth understanding before it carries your stack traces.

Editorial conclusion

Adopt the Exceptionless clients if you run a .NET application and want unhandled exceptions and log events collected centrally without building a reporting pipeline yourself, especially if you support several .NET flavours at once. Do not adopt it if your data residency or compliance requirements forbid sending exception payloads, since stack traces and request data leave your process, and check the licence file yourself rather than relying on the classification. Before you commit, start with the console sample so you can see exactly what gets sent, and read the Exceptionless documentation for the configuration of what is included and what is redacted.

Frequently asked questions

Official sources

1. exceptionless/Exceptionless.Net on GitHub
2. Issues
3. Project website
4. README
5. Releases