.NET Tools Cheat Sheet: APIs to UI

Core Concept LearningJuly 16, 20265 min readUpdated July 21, 2026

Shipping faster in .NET is less about memorizing NuGet packages and more about knowing which job needs a tool: identity, data access, tests, logs, app hosts, background work, reports, or UI components.

Map those eight lanes onto one multi-tenant SaaS API with a Blazor admin, SQL persistence, queued email, and PDF invoices. Start with a minimal API and structured logs below, then add a lane only when the feature or operating requirement demands it. Deeper auth patterns live in ASP.NET Core authorization types; structure lives in Clean Architecture in .NET.

Eight .NET toolkit lanes: from identity to UI

Learning path

Follow these checkpoints in order — each builds on the last.

A .NET stack decision is really eight separate lane decisions, from auth through UI — picking one tool per lane beats picking a single stack wholesale.
JWT alone covers a single trusted API — once you need SSO, refresh, or third-party login, that's the signal to bring in a full OIDC server or gateway.
EF Core's change tracking costs throughput on hot read paths — that's when Dapper's raw SQL or a specialty store earns its place instead.
Structured logs with a correlation ID are what turn a production incident into a traceable request instead of a guessing game.
Background jobs, messaging, PDF generation, and UI are four separate concerns — Hangfire failing doesn't need to take the request path down with it.
Start from the minimal toolkit that ships the slice — add the next tool only when a measured gap, not a poster, calls for it.

Map the eight lanes

Think in jobs, not brand names. Authentication proves who the caller is. ORM talks to databases. Testing and logging keep quality visible. Platforms are how you host (ASP.NET Core, Blazor, MAUI, Orleans, gRPC). Background runs jobs and messages. Reporting builds PDFs and grids. Frontend UI component libraries speed Blazor screens.

You rarely need every tool in a lane — one solid default per category beats a Frankenstein of six ORMs.

Quick reference

Auth · ORM · Test · Log · Platform · Background · Report · UI.
Pick defaults; swap when measurement or compliance forces it.
Ocelot is an API gateway — often listed near identity, not a token issuer.
Xamarin is legacy for new work — prefer .NET MAUI.

Remember this

A .NET stack decision is really eight separate lane decisions, from auth through UI — picking one tool per lane beats picking a single stack wholesale.

Authentication and platforms

Auth lane: JWT bearer validation for APIs, OAuth/OIDC for delegated login, and authorization-server products such as OpenIddict or Duende IdentityServer when your system must issue tokens. ASP.NET Core Identity manages application users and credentials; it does not by itself turn an app into a general-purpose OIDC provider. Ocelot is a gateway, not an identity provider.

Platforms: ASP.NET Core hosts HTTP APIs, Blazor builds .NET web UI, MAUI targets native clients, Orleans provides a virtual-actor model, and gRPC supplies strongly typed RPC contracts.

Use the built-in authentication handlers with an existing OIDC provider for most SaaS APIs. Operate an authorization server only when ownership of token issuance is a real product requirement.

Identity at the edge · platforms for APIs, UI, and grains

Quick reference

JWT · OAuth · IdentityServer · OpenIddict · Duende · Ocelot (gateway).
ASP.NET Core · Blazor · MAUI · Xamarin (legacy) · Orleans · gRPC.
Prefer official ASP.NET auth handlers before custom JWT parsing.
gRPC shines inside the mesh; REST/JSON still wins public browsers.

JWTOAuthDuendeOpenIddictOcelotASP.NET CoreBlazorMAUIgRPCOrleans

Remember this

JWT alone covers a single trusted API — once you need SSO, refresh, or third-party login, that's the signal to bring in a full OIDC server or gateway.

ORM and data access

EF Core is the default for most ASP.NET apps — change tracking, migrations, LINQ. Dapper wins when you want thin SQL and maximum control. NHibernate remains in mature enterprise codebases. Document-style or event-friendly stores appear via Marten (PostgreSQL documents/events). Micro-ORMs OrmLite and PetaPoco stay light when EF feels heavy.

When to use EF Core: greenfield CRUD with migrations. When to reach for Dapper: hot paths and complex SQL you already trust. When not to: three ORMs in one service — pick one write path.

Data access spectrum: EF Core productivity → Dapper control

Quick reference

EF Core — default productivity ORM.
Dapper — performance-oriented micro-ORM.
NHibernate — older full ORM still in estates.
Marten · OrmLite · PetaPoco — specialized or lightweight options.

EF CoreDapperNHibernateMartenOrmLitePetaPoco

Remember this

EF Core's change tracking costs throughput on hot read paths — that's when Dapper's raw SQL or a specialty store earns its place instead.

Testing and logging

Tests: xUnit is the community default for new .NET; NUnit and MSTest remain common. FluentAssertions (often labeled FluentAssert on slides) makes assertions readable; Moq mocks dependencies; Bogus builds fake data.

Logs & APM: Serilog is the usual structured-logging pick; NLog and log4net still appear. Ship to Seq, Elastic APM, or Splunk for search and ops.

When to use: xUnit + FluentAssertions + Moq for unit tests; Serilog → Seq/Elastic in prod. When not to: mocking everything — prefer fakes for domain purity where it helps.

Quality loop: tests assert · logs observe

Quick reference

xUnit · NUnit · MSTest — test runners.
FluentAssertions · Moq · Bogus — assert, mock, fabricate.
Serilog · NLog · log4net — logging libraries.
Seq · Elastic APM · Splunk — observe and search.

xUnitNUnitMSTestFluentAssertionsMoqBogusSerilogNLogSeqElastic APM

Remember this

Structured logs with a correlation ID are what turn a production incident into a traceable request instead of a guessing game.

Background work, reporting, and Blazor UI

Background: Hangfire and Quartz.NET schedule jobs; Coravel is a lighter scheduler for simpler apps. MassTransit plus RabbitMQ or Azure Service Bus handles messaging and sagas.

Reporting: QuestPDF, DinkToPdf, iText7 for documents; DevExpress, Syncfusion, Stimulsoft for commercial report/UI suites.

Frontend UI: Blazor component kits — MudBlazor, Blazorise, Radzen, plus Syncfusion UI, Telerik UI, and charting with LiveCharts2.

When to use Hangfire: fire-and-forget and recurring jobs with a dashboard. When to use a message bus: cross-service workflows. When not to: PDF generation on the request thread for large reports — queue it.

Jobs & messages · PDFs · Blazor component kits

Quick reference

Hangfire · Quartz.NET · Coravel — jobs/schedulers.
MassTransit · RabbitMQ · Azure Service Bus — messaging.
QuestPDF · DinkToPdf · iText7 · commercial report suites.
MudBlazor · Blazorise · Radzen · Syncfusion/Telerik · LiveCharts2.

HangfireQuartz.NETMassTransitRabbitMQAzure Service BusQuestPDFMudBlazorTelerik UI

Remember this

Background jobs, messaging, PDF generation, and UI are four separate concerns — Hangfire failing doesn't need to take the request path down with it.

A practical starter stack

For many greenfield APIs: ASP.NET Core + JWT/OAuth + EF Core + xUnit/Moq + Serilog→Seq + Hangfire for email/PDF jobs + QuestPDF + MudBlazor if you need an admin UI. Add MassTransit when services multiply; add Duende/OpenIddict when you become an identity provider.

Architecture design still matters more than collecting every logo — see Clean Architecture and SOLID guides on this site when the toolkit outgrows a single project.

Zoom: starter SaaS path — API → EF → job → PDF → admin UI

Quick reference

Default: ASP.NET Core · EF Core · xUnit · Serilog · Hangfire.
UI: MudBlazor or Radzen for speed; commercial kits when licensed.
Swap Dapper on measured hot paths only.
Practice: scaffold one API + one background job + one PDF endpoint.

Bootstrap one observable API

1dotnet new webapi -n BillingApi --use-controllers false2cd BillingApi3dotnet add package Serilog.AspNetCore4dotnet restore

Program.cs plus restore recovery

1using Serilog;2 3var builder = WebApplication.CreateBuilder(args);4builder.Host.UseSerilog((context, log) =>5    log.ReadFrom.Configuration(context.Configuration)6       .WriteTo.Console());7 8var app = builder.Build();9app.MapGet("/health", () => Results.Ok(new { status = "ok" }));10app.Run();11 12// If package restore is corrupt, run:13// dotnet nuget locals all --clear14// dotnet restore --force-evaluate

Remember this

Start from the minimal toolkit that ships the slice — add the next tool only when a measured gap, not a poster, calls for it.

Key takeaway

The useful stack is the smallest set that covers the jobs you actually have. Start with the ASP.NET Core host, one data path, one test framework, and structured logs; add schedulers, buses, document libraries, or UI suites only when a concrete feature creates that lane.

Practice (30 min): Paste the bootstrap commands, replace Program.cs, and run the app; GET /health should return { "status": "ok" }. Intentionally make package restore fail by adding a misspelled package ID, then remove it, clear the NuGet caches, and restore again. Pass when restore and build succeed, the health response matches exactly, and you can name the failure signal and removal criterion for one additional tool your app actually needs.