Best Libraries for ASP.NET Core in 2026 (Opinionated)

The best library in 2026 is often the one you do not install. .NET 10 now ships JSON, OpenAPI, resilience, rate limiting, and health checks in the box, and three of the packages that sat on every “must-have” list for a decade - AutoMapper, MediatR, and MassTransit - went commercial in 2025. So the honest answer to “what are the best libraries for ASP.NET Core” has changed more in the last 18 months than in the five years before it.

This is my opinionated, current shortlist for ASP.NET Core on .NET 10: one primary pick per job, what the framework now replaces, what changed its license, and the exact stack I install on a fresh Web API. No 23-item alphabetical dump - those lists are why people end up with five overlapping packages that the runtime already does for free.

TL;DR - the short list. For a typical ASP.NET Core .NET 10 API, here is the pick per job and whether the framework already covers it.

Read the table top to bottom and you already have the answer. The rest of this article is the why behind each pick, the licensing detail that matters for your company, and the starter stack at the end. Let’s get into it.

What makes a library worth a dependency in 2026?

A library earns a spot in your .csproj when it does a job the framework does not, does it materially better than hand-written code, and is maintained under a license your company can actually use. Those three filters - not in the box, clearly better, safe to ship - are what changed. The framework filter got stricter because .NET keeps absorbing common needs, and the license filter got real because maintainers started charging.

Every section below applies those three filters. When a library fails the first filter (the framework now does it), I say so and tell you to delete the package.

Before you install anything: what .NET 10 already gives you

This is the section the SEO-farm listicles skip, because “do not install a library” does not pad a top-23 post. But it is the highest-value advice on this page. Half the packages on a 2019-era must-have list are now dead weight on .NET 10.

Stop reaching for a NuGet package for any of these - the framework covers them:

1. JSON serialization. System.Text.Json is the default and handles 95% of cases. You do not need Newtonsoft.Json for a new API unless you hit a specific feature gap (polymorphic $type handling, JObject manipulation, certain converters). Reach for it deliberately, not by habit.
2. API documentation. Microsoft.AspNetCore.OpenAPI generates the OpenAPI document natively. Swashbuckle (Swagger) was removed from the ASP.NET Core templates in .NET 9, so a fresh project no longer ships it. Pair the built-in document with Scalar for the interactive UI.
3. Resilience (retries, circuit breakers, timeouts). Microsoft.Extensions.Http.Resilience is first-party and uses Polly under the hood. You get retry, circuit breaker, and timeout on your HttpClient with AddStandardResilienceHandler() and no separate Polly wiring.
4. Rate limiting. Built into the framework via Microsoft.AspNetCore.RateLimiting since .NET 7. No AspNetCoreRateLimit package needed.
5. Health checks. The framework ships health checks via Microsoft.Extensions.Diagnostics.HealthChecks. You only add a third-party package for specific probes (a particular database or broker).
6. Dependency injection. The built-in container covers the overwhelming majority of apps. You add Scrutor or Autofac only for assembly scanning or advanced features you can actually name.

The rule: install a library when the framework leaves a real gap, not because a 2018 tutorial told you to. Now to the libraries that still earn their place.

Logging: Serilog

Serilog is the best logging library for ASP.NET Core in 2026, and it is free under Apache-2.0. The framework gives you ILogger<T>, but that is an abstraction, not a logging pipeline. Serilog adds structured logging (every log is a queryable event with properties, not a flat string), a huge sink ecosystem (console, file, Seq, Elasticsearch, Application Insights, CloudWatch), and clean enrichment.

The reason structured logging matters: when an incident hits at 2 AM, you want to filter by RequestId or TenantId, not grep a text file. Serilog makes that the default shape of your logs.

builder.Host.UseSerilog((context, config) => config
    .ReadFrom.Configuration(context.Configuration)
    .Enrich.FromLogContext()
    .WriteTo.Console());

Serilog vs NLog is a real choice - both are mature and free - but I default to Serilog for the structured-first design and the sink ecosystem. NLog is a fine pick if your team already knows it.

Data access: EF Core, with Dapper for hot reads

EF Core 10 is the default ORM for ASP.NET Core, and it is first-party and MIT-licensed. It owns your schema through migrations, gives you LINQ, change tracking, and deep integration with the rest of the stack. For 90% of your endpoints, EF Core is the right tool and the performance difference against raw SQL goes unnoticed.

The judgment call: keep Dapper in your back pocket for the handful of read-heavy, latency-sensitive endpoints where EF Core’s translation gets in the way. Dapper is a thin layer over ADO.NET - you write the SQL, it maps the result to objects, and it is fast. A common, sane pattern in 2026 is EF Core for writes and most reads, Dapper for the three reporting queries that need raw speed. Do not start a project on Dapper-only because you read it is “faster” - you will rebuild change tracking and migrations by hand and regret it.

// EF Core for the write path
await db.Orders.AddAsync(order);
await db.SaveChangesAsync();

// Dapper for a hot read path
var rows = await connection.QueryAsync<OrderSummary>(
    "SELECT Id, Total, Status FROM Orders WHERE TenantId = @tenantId",
    new { tenantId });

Validation: FluentValidation

FluentValidation is my pick for anything beyond trivial validation, and it remains free under Apache-2.0. DataAnnotations ([Required], [MaxLength]) are fine for a couple of fields, but the moment you need conditional rules, cross-property checks, or async checks (is this email already taken?), attributes turn into a mess. FluentValidation puts the rules in a dedicated, testable class with a readable fluent API.

public class CreateProductValidator : AbstractValidator<CreateProductRequest>
{
    public CreateProductValidator()
    {
        RuleFor(x => x.Name).NotEmpty().MaximumLength(200);
        RuleFor(x => x.Price).GreaterThan(0);
        RuleFor(x => x.Sku).Matches("^[A-Z]{3}-[0-9]{4}$");
    }
}

The clean win is that validation lives outside your entities, so your domain models stay free of validation attributes and your rules are unit-testable in isolation.

Object mapping: write it by hand, then reach for Mapperly

This is where 2026 forces a real decision, because AutoMapper went commercial. In 2025, Jimmy Bogard (through Lucky Penny Software) moved AutoMapper to a dual license - the Reciprocal Public License 1.5 (RPL-1.5) plus a paid commercial license - starting with version 15. The plan was announced in April and the paid editions launched on July 2, 2025. It stays free for individuals and organizations under roughly $5M in annual revenue, but the terms changed, and a reciprocal license like RPL-1.5 is exactly the kind of thing your legal team will ask about.

My take, in order:

1. Map by hand first. For a request-to-entity or entity-to-DTO with a handful of properties, a plain mapping method is clearer, faster, and adds zero dependencies. Most mappings do not need a library at all.
2. When mapping is genuinely repetitive, use Mapperly. It is a source generator - it writes the mapping code at compile time, so there is no runtime reflection, no startup cost, and you can read the generated mapper. It is free under Apache-2.0 and is what several major frameworks moved to after the AutoMapper change.
3. Mapster is the other strong free option if you prefer its API.

// Mapperly - the mapping is generated at compile time
[Mapper]
public partial class ProductMapper
{
    public partial ProductDto ToDto(Product product);
}

If you already run AutoMapper and stay under the revenue cap, you are not on fire - but for new projects in 2026 I would not introduce a commercial-licensed mapper when a free source generator does the job better.

CQRS and the mediator pattern: MediatR is now paid too

MediatR also went commercial in 2025, under the exact same model as AutoMapper - same vendor (Lucky Penny Software), same RPL-1.5 dual license, same roughly $5M annual-revenue free tier, starting with MediatR version 13. That matters because MediatR was the default backbone of nearly every Clean Architecture template in .NET.

Here is the uncomfortable truth the old listicles will not tell you: most apps never needed MediatR in the first place. It exists to decouple a request from its handler via an in-process dispatcher, but for a typical API you can get the same separation with plain handler classes registered in DI and called directly. No magic, no pipeline reflection, no license question.

// A "handler" is just a class. No mediator required.
public sealed class CreateProductHandler(AppDbContext db)
{
    public async Task<Guid> Handle(CreateProductRequest request, CancellationToken ct)
    {
        var product = new Product(request.Name, request.Price);
        db.Products.Add(product);
        await db.SaveChangesAsync(ct);
        return product.Id;
    }
}

If you want the pipeline-behavior model (validation, logging, transactions as cross-cutting steps), there are free MediatR-compatible forks emerging, but I would reach for hand-rolled handlers plus a small pipeline before adding any dependency here.

Resilience: use the first-party package, not raw Polly

For retries, circuit breakers, and timeouts on outbound HTTP, use Microsoft.Extensions.Http.Resilience - it is first-party, MIT-licensed, and built on Polly. You no longer wire Polly by hand for the common case. One call adds a sensible default pipeline to your typed client.

builder.Services.AddHttpClient<PaymentClient>()
    .AddStandardResilienceHandler();

Polly itself is still excellent and free (BSD-3) if you need a custom resilience pipeline for non-HTTP work. But for the 90% case - a flaky downstream API - the Microsoft package is the right default because it ships tuned defaults and is maintained alongside the runtime.

Background jobs: Hangfire

Hangfire is my default for background and scheduled jobs in ASP.NET Core, and its core is free under LGPL-3.0. Fire-and-forget jobs, delayed jobs, and recurring (cron) jobs with a persistent store and - the reason I pick it over Quartz - a built-in dashboard you get with one line. You can see what ran, what failed, and retry from the UI.

Quartz.NET (Apache-2.0) is the alternative if you want a pure in-memory scheduler without the persistence and dashboard. For most web apps, Hangfire’s dashboard pays for itself the first time a nightly job silently fails. Note that Hangfire’s advanced add-ons (Hangfire.Pro) are commercial; the core you need is free.

Messaging: Wolverine or Rebus, because MassTransit is changing

MassTransit - the long-time default .NET message bus - is going commercial. MassTransit v9 moves to a commercial license, with the official commercial release landing in Q1 2026. The open-source v8 stays on Apache-2.0 but loses support at the end of 2026, and the commercial tier starts at a $400/month minimum - though organizations under roughly $1M in annual revenue may qualify for a free license.

If you are starting a new system in 2026, I would not build a long-term foundation on a library that is mid-transition. My free, MIT-licensed picks:

1. Wolverine - a modern command and message handler with a clean, low-ceremony model. Strong default for new projects.
2. Rebus - a mature, lightweight service bus that has been MIT and stable for years.
3. Raw client libraries (RabbitMQ.Client, Azure.Messaging.ServiceBus) when your needs are simple and you do not want a framework at all.

NServiceBus remains the heavyweight commercial option if you want vendor support and are already budgeting for it. The point: pick deliberately now, because the default everyone reached for is no longer free.

Real-time, API docs, and testing (the quick picks)

Real-time: SignalR. First-party, MIT, and still the answer for WebSocket-based features - live dashboards, notifications, chat. No third-party library competes for the mainstream case.

API docs: built-in OpenAPI + Scalar. The framework emits the OpenAPI document; Scalar renders a clean, modern interactive UI. This is the 2026 replacement for the Swagger UI that used to ship by default.

Testing: xUnit + NSubstitute + Testcontainers. xUnit is the de-facto test framework. NSubstitute is my mocking pick (a clean API, and it sidesteps the licensing controversy Moq created in 2023 - Moq still works, but NSubstitute avoids the question). Testcontainers spins up a real PostgreSQL or Redis in Docker for integration tests, so you test against the real thing instead of an in-memory fake that lies to you. All three are free.

The “going commercial” reality check

This is the single most important table on this page, and no competing listicle has it. If you are picking libraries in 2026, you need to know which “free” defaults are not free anymore.

The pattern is clear: prolific maintainers are moving to sustainable funding, and the libraries that defined .NET architecture templates for a decade now carry a license question. None of this means you must rip them out today if you are under the revenue caps. It means for new projects, you should know the free, modern alternatives exist - and in most cases they are genuinely better-engineered (source generators, no runtime reflection) than what they replace.

My default starter stack for a new ASP.NET Core API

Here is exactly what I install on a fresh .NET 10 Web API - nothing that the framework already covers, nothing with a license question I would not want to answer.

# Data
dotnet add package Microsoft.EntityFrameworkCore.Design
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL

# Validation
dotnet add package FluentValidation.AspNetCore

# Logging
dotnet add package Serilog.AspNetCore
dotnet add package Serilog.Sinks.Console

# API docs UI (the OpenAPI document is built-in)
dotnet add package Scalar.AspNetCore

# Resilience is built-in:
dotnet add package Microsoft.Extensions.Http.Resilience

# Testing (test project)
dotnet add package xunit
dotnet add package NSubstitute
dotnet add package Testcontainers.PostgreSql

I add Dapper when a read path needs it, Hangfire when there are background jobs, Mapperly when mapping gets repetitive, and a messaging library (Wolverine) only when the system actually needs a bus. That is the whole philosophy: start lean, add a library when a real gap appears, and never install something the runtime already does.

Key Takeaways

1. The framework is the first library. On .NET 10, JSON, OpenAPI, resilience, rate limiting, health checks, DI, and real-time (SignalR) are all built in. Delete the packages that duplicate them.
2. Three former defaults went commercial. AutoMapper (v15, 2025), MediatR (2025), and MassTransit (v9, 2026) now carry license questions. Know the free alternatives: Mapperly, hand-rolled handlers, and Wolverine/Rebus.
3. The still-free, still-best picks: Serilog (logging), EF Core + Dapper (data), FluentValidation (validation), Hangfire (jobs), Scalar (API docs UI), xUnit + NSubstitute + Testcontainers (testing).
4. Pick one per job, not five. A lean, deliberate stack beats a 20-package pile of overlapping dependencies every time.
5. Map by hand before you add a mapper. Most mappings are a method, not a library.

Frequently Asked Questions

Summary

The best libraries for ASP.NET Core in 2026 are a shorter list than they used to be, because .NET 10 absorbed so much of what we used to install, and because the licensing ground shifted under AutoMapper, MediatR, and MassTransit. The winning move is the same one good engineers have always made: lean on the framework, add a library only when it does a job the runtime does not, and check the license before you commit a long-term dependency.

Start with Serilog, EF Core, FluentValidation, and the built-in OpenAPI plus Scalar. Add Dapper, Hangfire, Mapperly, and a free message bus when the project earns them. Skip anything the framework already does. That stack is current, almost entirely free, and small enough to actually understand.

Happy Coding :)