mir-backend-dotnet-aspnetcorelisted

Make It Right (ASP.NET Core module). ASP.NET Core + Minimal APIs + EF Core + Entity Framework migrations specific reliability augmentation. Use alongside mir-backend and mir-backend-dotnet when the target stack is ASP.NET Core or Minimal APIs — it carries the mechanical footguns the runtime-agnostic tiers deliberately omit: DI lifetime errors in practice (AddDbContext Scoped vs singleton capture, IHttpContextAccessor caveats), middleware pipeline ORDER (UseRouting → UseAuthentication → UseAuthorization → endpoints; wrong order silently disables auth), model binding overposting / mass assignment onto EF entities, response DTO discipline to prevent field leakage, EF Core N+1 (lazy loading raises in async contexts, use Include/projection/AsNoTracking), async-all-the-way in endpoints with CancellationToken from the request, object-level authorization (IDOR via valid token without resource check), antiforgery for cookie auth, and the Options pattern for config. TRIGGER only when the .NET backend stack uses ASP.NET
anantbhandarkar/make-it-right · ★ 12 · API & Backend · score 83

Install: claude install-skill anantbhandarkar/make-it-right

# /mir-backend-dotnet-aspnetcore · Make It Right (ASP.NET Core) Bottom tier of the chain: `mir-backend` (generic gates) → `mir-backend-dotnet` (CLR runtime model) → **this** (ASP.NET Core / EF Core / Minimal API library mechanics). Run the gates first; load the .NET runtime tier for async model, DI lifetime theory, and thread-pool concerns; reach for *this* at Gate 5 (design mechanics), Gate 6 (implementation), and Gate 7 review. **Runtime-level concerns (sync-over-async deadlock, ConfigureAwait(false), ValueTask, IDisposable, CancellationToken propagation, captive dependency theory) live in `mir-backend-dotnet` — not here.** **Stack assumed:** ASP.NET Core 8+ (controllers or Minimal APIs) · EF Core 8 · SQL Server / PostgreSQL · `Microsoft.EntityFrameworkCore.Design` migrations. If the project uses Dapper or a different ORM, note the divergence before applying EF-specific guidance. ## The ASP.NET Core footguns AI walks into most ### 1. DI lifetimes in practice — AddDbContext is Scoped; singletons must not capture it `AddDbContext<T>()` registers `DbContext` as **Scoped** (one instance per HTTP request). The captive dependency problem (runtime tier) surfaces concretely here: ```csharp // WRONG — MyWorker is Singleton; captures a Scoped DbContext at construction services.AddSingleton<MyWorker>(); services.AddDbContext<AppDbContext>(); public class MyWorker(AppDbContext db) { ... } // db lives forever = cross-request bleed ``` ```csharp // RIGHT — use IDbContextFactory