NuGet Packages for ASP.NET Core

A useful NuGet package list for an ASP.NET Core application begins with the web SDK and adds only the capabilities the application can name and test.

The ASP.NET Core shared framework is a stocked shelf: routing, configuration, dependency injection, logging abstractions, data protection, and many other web features already ship together. NuGet supplies the missing tools for a specific database, API contract, integration, or test boundary.

Start with the Shared Framework

A project using Microsoft.NET.Sdk.Web implicitly references Microsoft.AspNetCore.App. Ordinary web applications therefore start without separate package references for MVC, dependency injection, configuration, localization, data protection, or SignalR.

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>
</Project>

Check the target framework before copying any package command. Package families maintained with .NET commonly align their major releases with the target framework, while third-party projects publish their own compatibility guidance.

Use the SDK template as the baseline, then inspect the current dependency set before adding anything:

dotnet list package --include-transitive
dotnet list package --outdated --include-transitive
dotnet list package --vulnerable --include-transitive

These commands expose direct and transitive dependencies, available updates, and reported vulnerabilities. Package review still requires release notes and project documentation because a clean restore cannot prove that an integration matches the application.

Choose Packages by Missing Capability

Each package should answer a concrete requirement and have a test that proves the integration works.

• Microsoft.EntityFrameworkCore plus a provider supports relational models, LINQ queries, change tracking, and migrations.
• Microsoft.AspNetCore.OpenApi generates OpenAPI documents from ASP.NET Core endpoints.
• Microsoft.AspNetCore.Authentication.JwtBearer validates bearer tokens issued through OAuth or OpenID Connect systems.
• Microsoft.Extensions.Http.Resilience adds configured resilience handlers to outbound HttpClient calls.
• Microsoft.Extensions.Caching.Hybrid coordinates local and optional distributed caching with stampede protection.
• OpenTelemetry.Extensions.Hosting connects .NET telemetry to OpenTelemetry configuration and exporters.
• Serilog.AspNetCore integrates Serilog request logging and host setup.
• Microsoft.AspNetCore.Mvc.Testing boots the real web host inside integration tests.

Add package names through the CLI without copying stale version pins from an article:

dotnet add src/Store.Api package Microsoft.AspNetCore.OpenApi
dotnet add src/Store.Api package Microsoft.EntityFrameworkCore.SqlServer
dotnet add tests/Store.Api.Tests package Microsoft.AspNetCore.Mvc.Testing

Select the exact compatible release through the project's dependency policy, official compatibility documentation, and package audit process. The project paths keep runtime packages in the web app and the testing package in the integration-test project.

Data Access and API Contracts

EF Core needs a provider for the database the application will actually use. SQL Server, PostgreSQL, SQLite, and MySQL-family providers differ in SQL translation, data types, migration behavior, and operational tooling.

Use EF Core when the application benefits from a relational model, change tracking, and reviewed migrations. Direct SQL or another data-access library can serve applications that need exact query control or have a small, read-heavy query surface.

Microsoft.AspNetCore.OpenApi fits APIs that need a machine-readable OpenAPI document. A browser UI, client generator, or additional documentation interface is a separate requirement with its own package choice.

builder.Services.AddOpenApi();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();
}

This small registration creates the application's document-generation boundary. Add a UI package only when developers or API consumers need that interface.

Authentication and Outbound Resilience

Microsoft.AspNetCore.Authentication.JwtBearer fits APIs that receive access tokens from a trusted OAuth or OpenID Connect issuer. Installation is the smallest part of the work because token validation also needs a correct issuer, audience, signature, expiration policy, and authorization design.

Microsoft.Extensions.Http.Resilience fits services that call remote APIs and need controlled timeouts, retries, or circuit breakers. Configure each resilience policy around the specific remote operation. A read-only catalog lookup may tolerate a retry, while a payment or order command needs an idempotency design before automatic repetition is safe.

Caching and Observability

Microsoft.Extensions.Caching.Hybrid fits expensive read paths with stable cache keys and known lifetimes. Define ownership and invalidation before storing user-specific, tenant-specific, or permission-sensitive results.

OpenTelemetry packages fit applications that need traces and metrics exported to a collector or monitoring backend. Start with OpenTelemetry.Extensions.Hosting and add instrumentation packages only for boundaries the application actually uses.

ASP.NET Core already supports structured ILogger messages. Choose Serilog.AspNetCore when Serilog's request logging, sinks, enrichment, or existing operational setup provides a required path from application events to the people investigating them.

Integration Testing

The Microsoft.AspNetCore.Mvc.Testing package belongs only in a dedicated test project. Its WebApplicationFactory can boot routing, middleware, dependency injection, model binding, filters, and authorization with test configuration.

public sealed class StatusApiTests
    : IClassFixture<WebApplicationFactory<Program>>
{
    [Fact]
    public async Task StatusEndpointReturnsSuccess()
    {
        await using var factory = new WebApplicationFactory<Program>();
        using var client = factory.CreateClient();

        var response = await client.GetAsync("/status");

        response.EnsureSuccessStatusCode();
    }
}

// Store.Api/Program.cs, after app.Run()
public partial class Program { }

The public partial declaration exposes the top-level Program class to the test project. This test catches host wiring failures that an isolated method test cannot reach. Use the real database provider or a close substitute when provider behavior affects the result.

Packages that Need a Clear Case

Several established packages remain useful when their specific tradeoff matches the application.

• AutoMapper fits broad, repetitive mapping rules with tests and visible configuration. Explicit projections fit small APIs with a few contracts.
• MediatR fits applications that need a mediator pipeline across many commands or queries. Direct service calls keep smaller applications easier to trace.
• FluentValidation fits reusable validation rules and its current ASP.NET Core integration guidance. Endpoint-local checks may be clearer for a small Minimal API.
• Newtonsoft.Json fits compatibility requirements or JSON behaviors unavailable in System.Text.Json.
• Swashbuckle.AspNetCore and NSwag.AspNetCore fit UI or client-generation requirements beyond first-party document generation.

The decision should name the repetition being removed, the integration owner, and the behavior covered by tests. That standard keeps the stocked shelf usable instead of filling it with duplicate tools.

Common Pitfalls & Debugging

The Package Duplicates Framework Code

Symptom: the project references a package for a capability already supplied by Microsoft.AspNetCore.App. Cause: an older package list was copied into a newer project. Fix: check the shared-framework documentation, remove the duplicate reference, restore, and run integration tests.

A Package Targets a Different Framework Line

Symptom: restore reports compatibility warnings or startup fails after a package change. Cause: the selected package release does not support the project's target framework. Fix: read the package's official compatibility guidance and choose a maintained release for the target framework.

A Retry Repeats a Command

Symptom: an outbound request creates duplicate payments, orders, or messages. Cause: a resilience handler retried a state-changing operation without idempotency protection. Fix: restrict retries to safe operations or add an idempotency key and server-side duplicate detection.

Frequently Asked Questions

Is Newtonsoft.Json still needed in a modern ASP.NET Core app?

Not by default. System.Text.Json has been the built-in serialiser since ASP.NET Core 3.0 and is faster with fewer allocations. Add Newtonsoft.Json for a specific compatibility need, such as converter patterns it still handles or an existing codebase already built on it.

How do you check a NuGet package for known vulnerabilities?

Run dotnet list package with the vulnerable and include-transitive options, which reports advisories for your packages and everything they pull in. Read a clean result as nothing disclosed rather than proven safe, since it only covers published advisories.

Do minimal APIs need different packages than controller-based APIs?

Mostly no. Both run on the same framework and share the same choices for data access, resilience, caching, and testing. The difference is narrow: some MVC-oriented tooling targets controllers, while minimal APIs commonly pair with Microsoft.AspNetCore.OpenApi for documentation.

What is the difference between dotnet add package and editing the csproj?

The end state is the same PackageReference entry. The command resolves and writes the version for you; editing by hand gives control over exact pins and metadata such as PrivateAssets, at the cost of supplying the version yourself and running a restore afterwards.

Package Review Checklist

1. Confirm the shared framework does not already supply the capability.
2. Name the application requirement and the project that owns the dependency.
3. Verify target-framework compatibility in official package documentation.
4. Review maintenance, licensing, transitive dependencies, and security advisories.
5. Add an integration test that exercises the package boundary.
6. Record the package's upgrade owner and remove it when the requirement disappears.

Next Steps

Begin with the web SDK, add one package for one verified requirement, and test the resulting application boundary. Continue with the C# frameworks guide for request-pipeline, EF Core, testing, worker, and deployment decisions.

Use the SQL programming guide before choosing a database provider, because the database workload should determine the provider and persistence design.