Skip to main content
N
All NuGet guides

Decision guide

Logging packages for .NET

Start with the logging abstraction already used by the host. The meaningful choice is usually the provider and output pipeline, not whether an application should log at all.

The decision to make

Which logging provider fits an ASP.NET Core or worker application?

  • Whether the application already uses Microsoft.Extensions.Logging abstractions.
  • Required structured fields, enrichment, filtering and correlation behavior.
  • The destinations you operate: console, files, OpenTelemetry, a log server or cloud services.
  • Operational needs such as JSON output, retention, sampling and failure handling.

Shortlist and trade-offs

These options are starting points, not an exhaustive market list. Verify the current release, compatibility, license and advisory information for your project on the linked package pages.

Microsoft.Extensions.Logging

The standard logging abstraction and default implementation used throughout modern .NET hosting.

Inspect package
Best fit
Applications that want provider-agnostic logging and straightforward integration with .NET hosts.
Validate first
Advanced routing and event shaping are supplied by providers or additional configuration, not the abstraction alone.

Serilog.AspNetCore

Serilog integration for ASP.NET Core, centred on structured events and a large sink ecosystem.

Inspect package
Best fit
Teams that need rich structured event properties and deliberate control over log destinations.
Validate first
The desired sinks and configuration need to be selected and operated explicitly.

NLog.Web.AspNetCore

NLog integration for ASP.NET Core with flexible target and rule configuration.

Inspect package
Best fit
Teams already using NLog or requiring its configuration-oriented routing model.
Validate first
Avoid adding a second logging pipeline when the existing provider already meets the requirement.

When to revisit this choice

Review logging choices when observability moves to OpenTelemetry, when retention requirements change, or when sensitive data rules are introduced.

Data, method and limits

Sources: the public NuGet v3 registry and NuBrowse editorial review. Refresh: package pages read current registry metadata when viewed; guide text is revised separately. Method: the shortlist favours distinct use cases and spells out trade-offs instead of calculating a quality score. Limit: validate the specific version, license, framework and operational requirements in your project.