log4net for .NET: one logging API, many appenders, and a dated README

One logging call, many destinations: what log4net is for

Apache log4net is a logging API for .NET, and its reason to exist is the separation of where you log from how you log. Application code calls a logger, the library decides where the event ends up and how it is formatted. That indirection is the whole design: a console during development, a file in a batch job, a database table in production, all behind the same call site.

The project has unusual staying power for a logging library. It graduated from the Apache Incubator in February 2007 and has stayed inside the Apache Logging Services project since. It ships as the NuGet package named log4net, and its homepage is the project site at logging.apache.org/log4net. The topics attached to the repository list syslog and logger alongside the obvious dotnet and library entries.

This matters for an evaluation. A logging library is infrastructure you will not replace casually, and the cost of choosing one is dominated by how much of it your application ends up coupled to. log4net couples you to a configuration model and to a set of appender types, both of which have to survive a decade of upgrades in your codebase.

Appenders, layouts and the split examples solution

The examples directory in the repository is the clearest picture of how log4net is meant to be used. It is not a single demo project but a solution, examples/examples.sln, divided into folders named Appenders, Layouts, Extensibility, Extensions, Performance, Tutorials and Maui.

That split is the architecture. Appenders are the destinations a log event can travel to. Layouts are the formatting rules that turn an event into a line of text. Extensibility and Extensions cover the path where you add your own appender or layout, which tells you the extension points are meant to be used rather than merely tolerated.

The Performance folder deserves attention because it is where the library exposes its own overhead assumptions. Tutorials and Maui cover the application-facing side. If you are evaluating the library, the per-folder layout is a good map of the decisions you will face: destination, format, custom code path, cost, and the wiring that ties them together. Nothing in the repository tells you which of those folders you can skip.

net462 and netstandard2.0 are the whole target surface

The README states that log4net targets net462 and netstandard2.0. Two targets, and no modern target framework named alongside them, so a plan that depends on net8.0 or net10.0 specific assemblies is not covered by the documented build.

The Dockerfile in the repository root explains how the older target is handled. Its comment states that net4x targets are compiled against the Microsoft.NETFramework.ReferenceAssemblies packages that the .NET SDK references implicitly, and that Mono is not required because the image compiles but does not execute net4x assemblies. So the standardisation is real for building, but there is a catch: the container can produce a net462 assembly and cannot run it.

There is also a tooling note in the same file, stating that Ubuntu 24.04 (noble) is the only Ubuntu variant published for .NET 10, and that the reference is fully qualified, so it needs no registry configuration and no login. Anyone reproducing the build locally on a different Linux distribution will need to check the base image availability first.

Reproducing the build from the repository Dockerfile

The repository carries a Dockerfile that builds the solution from a .NET 10 SDK image. The sequence below is the image definition as committed, trimmed to the lines that affect the build. The ADD step copies the checkout into the image, the two RUN steps restore and build src/log4net.sln, and the container starts a shell rather than a service, which fits a library that has nothing to run.

FROM mcr.microsoft.com/dotnet/sdk:10.0-noble
ENV DOTNET_NOLOGO=true
ENV DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true

ADD . /logging-log4net
RUN dotnet restore /logging-log4net/src/log4net.sln
RUN dotnet build -c Release /logging-log4net/src/log4net.sln
CMD ["/bin/bash"]

Three details are worth copying if you set up your own container. The environment switches suppress the .NET first-run banner and logo, which keeps build logs readable in CI output. The solution path is src/log4net.sln rather than the solution at the repository root, so a naive build of the top level will not match the container behaviour. And the working copy is copied into /logging-log4net, which matters if your build script or test tooling assumes a particular absolute path.

SmtpAppender is deprecated and the mail extension is a separate package

The README lists a single extension and it is a replacement, not an addition. log4net.Ext.Mail is described as a MailKit-based SMTP appender for sending log events via email, and the README calls it the recommended replacement for the deprecated SmtpAppender.

That means a real decision point for anyone currently emailing log events. The built-in SmtpAppender is on a deprecation path, while the supported path lives in a separate NuGet package that you add to your own dependency list and that carries its own MailKit dependency tree. The trade-off is a clean exit from a deprecated component in exchange for another package and another transitive set of libraries to track through upgrades.

The second point is scope. Only the mail extension is called out in the README. No other extension package is named there, so if you have heard of community appenders for databases or message queues, the repository does not endorse them and this page cannot confirm anything about them. Check the project site before planning a long-lived dependency on any specific extension.

The README does not document configuration or a first log call

This is the most consequential gap for anyone starting a new project with log4net. The README points readers to the project web site for the latest documentation, and that is the end of it. There is no installation command, no configuration snippet, no logger declaration and no sample appender definition in the README text. The repository itself does carry a doc/ folder with CONTRIBUTING.md, BUILDING.md and RELEASING.md, and an antora-playbook.yaml at the root, which points to a documentation toolchain, but the configuration reference is not in the README.

So the onboarding sequence is not a copy and paste. You take the log4net package from NuGet, then you go read logging.apache.org/log4net to learn the configuration keys and the appender types, then you come back to your own code. The examples solution is the other source of truth, and it is a set of working projects rather than a document.

If your evaluation depends on a two-hour integration, that time is real and should be budgeted. Judge the library on the configuration model once you have read it, not on this README, because the README is an index and a project description rather than a usage guide.

Version churn between 3.4 and 3.5 and what the package version signals

Three release tags are listed for the recent past. rel/3.4.0 was tagged on 2026-08-18, rel/3.5.0 on 2026-09-25, and rc/3.4.1-preview.1 on 2026-08-20, which is a preview on the older minor line landing after the newer minor release.

The package metadata at the repository root adds a detail worth checking. The package.json declares the name as log4net and the version as 3.5.1, with the licence field set to Apache-2.0 and the homepage pointing at the GitHub project page. The declared version sits ahead of the newest listed release tag of 3.5.0, which tells you the default branch is already carrying work for a version that has not shipped as a release. If you pin a package version, pin it to a tagged release rather than to whatever the manifest says.

On maintenance, the licence field on the repository says Apache-2.0, the repository is not archived, and the last push was on 2026-10-12. That is a recent commit on a project that has shipped for nearly two decades. The upgrade cost is therefore about the size of your own configuration, not about a dormant library.

Editorial conclusion

log4net suits teams already shipping .NET Framework or .NET Standard libraries that need a configurable logging back end without taking on a hosting platform. It does not suit teams who want a self-contained logging product with structured pipelines or a UI, because the repository ships a library and examples rather than a service. Before adopting, read the configuration reference on logging.apache.org/log4net, check that your target runtime still falls inside the net462 and netstandard2.0 range, and confirm that any SMTP delivery goes through the separate log4net.Ext.Mail package rather than the deprecated SmtpAppender.

Frequently asked questions

Official sources

1. apache/logging-log4net on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases