.NET Tools Cheat Sheet: APIs to UI
Shipping faster in .NET is less about memorizing every NuGet package and more about knowing which lane to open: identity, data access, tests, logs, app hosts, background work, reports, and UI kits.
This cheat sheet maps eight tool categories — from JWT and EF Core to Serilog, Hangfire, QuestPDF, and MudBlazor — so you pick a default stack instead of debating logos. Deeper auth patterns live in [ASP.NET Core authorization types](/blog/aspnet-core-authorization-types); structure in [Clean Architecture in .NET](/blog/clean-architecture-dotnet).
Running example: a multi-tenant SaaS API with a Blazor admin UI, SQL persistence, background email jobs, and PDF invoices.
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
I can name eight .NET toolkit lanes from auth through UI.
Authentication and platforms
Auth lane: JWT for APIs, OAuth for delegated login, and full OIDC stacks — IdentityServer, OpenIddict, Duende — when you need an authorization server. Ocelot sits at the edge as a gateway (routing, aggregation), not as your identity provider.
Platforms: ASP.NET Core for HTTP APIs and web hosts, Blazor for .NET UI in the browser or hybrid, MAUI (successor mindset to Xamarin) for native clients, Orleans for actor-style grain systems, gRPC for efficient service-to-service contracts.
When to use: JWT + ASP.NET Core Identity for most SaaS APIs; add Duende/OpenIddict when you are the IdP. When not to: standing up IdentityServer for a single internal CRUD app.
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.
Remember this
I know when JWT suffices and when a full OIDC server or gateway enters the stack.
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.
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.
Remember this
I can choose EF Core vs Dapper vs a specialty store for a given service.
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.
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.
Remember this
I can name a default test stack and a structured logging path for .NET apps.
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.
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.
Remember this
I can pick job, messaging, PDF, and Blazor UI tools for a SaaS slice.
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.
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.
Remember this
I can propose a minimal .NET toolkit and know what to add next.
The “best” .NET tools are the ones that cover your lanes without overlap: identity, data, tests, logs, host, background work, documents, and UI. Start narrow — ASP.NET Core, EF Core, xUnit, Serilog, Hangfire — then graduate to buses, OIDC servers, and commercial UI only when the product demands it.
Your homework: list your next feature. Assign one tool per lane (or “none yet”). Delete any second tool in the same lane unless you can name the concrete gap it fills.
Related Articles
Explore this topic