Forem: Libin Tom Baby

Debugging Production and Performance Issues in .NET — A Practical Guide

Libin Tom Baby — Fri, 01 May 2026 14:00:00 +0000

Application Insights, structured logging, SQL query plans, ILogger, BenchmarkDotNet, pagination vs full-table fetch, memory dumps

Production bugs and performance problems are different from development bugs.

You cannot attach a debugger. You have limited visibility. The system is under real load. And in many cases, the issue is not an exception — it's slow code, a memory leak, or a database query that works fine with 100 rows but falls apart with 4 million.

Part 1: Debugging Production Issues

Structured Logging — Your First Line of Defence

Production debugging starts and ends with good logs.

// ❌ Bad — unstructured, unsearchable
_logger.LogInformation("User " + userId + " placed order " + orderId);

// ✅ Good — structured, queryable
_logger.LogInformation(
    "User {UserId} placed order {OrderId} for {Product}",
    userId, orderId, product);

Structured logging lets you query logs by field values in Application Insights, Seq, Datadog, or any log aggregator.

Correlation IDs

Every request should carry a trace ID from entry to exit — across services.

app.Use(async (context, next) =>
{
    var correlationId = context.Request.Headers["X-Correlation-Id"]
        .FirstOrDefault() ?? Guid.NewGuid().ToString();

    context.Response.Headers["X-Correlation-Id"] = correlationId;

    using (_logger.BeginScope(new { CorrelationId = correlationId }))
    {
        await next();
    }
});

When a user reports a bug with the correlation ID, you can pull every log entry for that request in seconds.

Application Insights

The Azure-native monitoring solution for .NET apps.

builder.Services.AddApplicationInsightsTelemetry();

Out of the box:

Request traces with duration and status codes
Dependency tracking (SQL queries, HTTP calls, queues)
Exception capture with full stack traces
Live Metrics for real-time monitoring
Custom events and metrics

_telemetryClient.TrackEvent("OrderCreated", new Dictionary<string, string>
{
    { "OrderId", orderId.ToString() },
    { "CustomerId", customerId }
});

Health Checks

builder.Services.AddHealthChecks()
    .AddDbContextCheck<AppDbContext>()
    .AddUrlGroup(new Uri("https://api.external.com/health"), "ExternalApi");

app.MapHealthChecks("/health");

Part 2: Debugging Performance Issues

The Dashboard Problem — Millions of Records

The most common real-world performance issue.

// ❌ The problem — loading all 4 million rows into memory
public async Task<List<OrderDto>> GetDashboardOrders()
{
    return await db.Orders
        .Select(o => new OrderDto(o.Id, o.Product, o.Total))
        .ToListAsync(); // 4,200,000 rows loaded. Memory spikes. Timeout.
}

The fix has multiple layers.

Layer 1: Pagination

public async Task<PagedResult<OrderDto>> GetDashboardOrders(int page, int pageSize = 50)
{
    var total = await db.Orders.CountAsync();
    var items = await db.Orders
        .OrderByDescending(o => o.CreatedAt)
        .Skip((page - 1) * pageSize)
        .Take(pageSize)
        .Select(o => new OrderDto(o.Id, o.Product, o.Total))
        .AsNoTracking()
        .ToListAsync();

    return new PagedResult<OrderDto>(items, total, page, pageSize);
}

Layer 2: Projection — select only what you need

// ✅ Only the columns needed
.Select(o => new OrderDto(o.Id, o.Product, o.Total))

// ❌ Loads entire object graph
.Include(o => o.Lines)

Layer 3: AsNoTracking() for read-only queries

.AsNoTracking() // Skips EF change tracking overhead

Layer 4: Compiled Queries for hot paths

private static readonly Func<AppDbContext, string, Task<List<OrderDto>>> GetOrdersByCustomer =
    EF.CompileAsyncQuery((AppDbContext db, string customerId) =>
        db.Orders
            .Where(o => o.CustomerId == customerId)
            .Select(o => new OrderDto(o.Id, o.Product, o.Total))
            .AsNoTracking());

var orders = await GetOrdersByCustomer(db, customerId);

SQL Query Plans — Finding Slow Queries

Most performance problems are SQL problems, not C# problems.

Step 1: Log EF Core SQL output

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString)
           .LogTo(Console.WriteLine, LogLevel.Information)
           .EnableSensitiveDataLogging());

Step 2: Run the query in SSMS

Press Ctrl+M to include the actual execution plan. Look for:

Full table scans — no index is being used
Key lookups — covering index needed
Sort operators — missing index on ORDER BY column
Hash joins on large tables — join column not indexed

Step 3: Add missing indexes

CREATE NONCLUSTERED INDEX IX_Orders_CustomerId_CreatedAt
ON Orders (CustomerId, CreatedAt DESC)
INCLUDE (Product, Total, Status);

Or via EF Core migrations:

modelBuilder.Entity<Order>()
    .HasIndex(o => new { o.CustomerId, o.CreatedAt })
    .IsDescending(false, true);

BenchmarkDotNet — Measuring C# Performance

[MemoryDiagnoser]
public class OrderMappingBenchmark
{
    private List<Order> _orders = Enumerable.Range(0, 10_000)
        .Select(i => new Order { Id = i, Product = "Widget", Total = 9.99m })
        .ToList();

    [Benchmark]
    public List<OrderDto> ManualMapping()
        => _orders.Select(o => new OrderDto(o.Id, o.Product, o.Total)).ToList();

    [Benchmark]
    public List<OrderDto> AutoMapperMapping()
        => _mapper.Map<List<OrderDto>>(_orders);
}

dotnet run -c Release

The N+1 Query Problem

The most common EF Core performance issue.

// ❌ N+1 — one query for orders, then one per order for customer
var orders = await db.Orders.ToListAsync();
foreach (var order in orders)
{
    var customer = await db.Customers.FindAsync(order.CustomerId); // 1 query per order!
}

// ✅ Single query with Include
var orders = await db.Orders
    .Include(o => o.Customer)
    .ToListAsync();

Memory Profiling — Diagnosing Leaks

Signs of a memory problem:

Gen 2 GC collections increasing over time
Memory usage that never drops after load
OutOfMemoryException under sustained traffic

Tools: dotMemory (JetBrains), Visual Studio Diagnostic Tools, PerfView

Quick in-code check:

_logger.LogInformation(
    "GC Gen0={Gen0} Gen1={Gen1} Gen2={Gen2} TotalMemory={TotalMB}MB",
    GC.CollectionCount(0),
    GC.CollectionCount(1),
    GC.CollectionCount(2),
    GC.GetTotalMemory(false) / 1024 / 1024);

Interview-Ready Summary

Structured logging is non-negotiable — use named parameters, not string concatenation
Correlation IDs link every log entry across a full request lifecycle
Application Insights provides out-of-the-box tracing, exceptions, and dependencies
The dashboard performance fix: paginate + project + AsNoTracking() + indexes
Never load millions of rows — use .Skip().Take() or cursor-based pagination
Check SQL execution plans for table scans and missing indexes
BenchmarkDotNet for C# micro-benchmarks
N+1 queries are the most common EF Core trap — fix with Include() or projection

A strong interview answer:

"For production debugging, structured logging with correlation IDs and Application Insights are the foundation — they let you trace any request across the system. For performance issues like the dashboard problem, the fix is almost always: don't load what you don't need. That means pagination with Skip/Take, projection to select only required columns, AsNoTracking for read-only queries, and checking the SQL execution plan for missing indexes. The N+1 query is the most common EF Core trap — fixed with eager loading or projecting into a join."

⭐ Add-On — The Production Debugging Checklist

When something goes wrong in production, follow this order:

Check logs — is there an exception? What's the correlation ID?
Check Application Insights — is it a slow dependency (SQL, HTTP)?
Check resource metrics — is CPU/memory/connection pool exhausted?
Reproduce in staging — enable detailed EF logging, check SQL plans
Add targeted logging — deploy a fix that adds more visibility
Benchmark if needed — BenchmarkDotNet for hot-path issues
Fix, measure, verify — confirm the fix with before/after metrics

How to Pass Data Between Controllers in ASP.NET Core

Libin Tom Baby — Wed, 29 Apr 2026 14:00:00 +0000

TempData, Session, RouteData, RedirectToAction with params, service-layer approach (the right way)

It's a common scenario: one controller handles a form submission, and you need to pass a message or result to another controller's action after a redirect.

But passing data between controllers is trickier than it looks — and most approaches have hidden tradeoffs.

Why You Can't Just Use a Variable

HTTP is stateless.

A redirect from OrderController to DashboardController is a completely new HTTP request. Any variables you set in the first request are gone by the time the second request arrives.

You need a mechanism to persist data across that boundary.

Option 1: TempData

TempData is a dictionary that persists for exactly one redirect — cleared after the next request reads it.

// OrderController.cs
[HttpPost]
public IActionResult Create(CreateOrderDto dto)
{
    var orderId = _orderService.Create(dto);
    TempData["SuccessMessage"] = "Order created successfully!";
    TempData["OrderId"] = orderId.ToString();
    return RedirectToAction("Index", "Dashboard");
}

// DashboardController.cs
[HttpGet]
public IActionResult Index()
{
    var message = TempData["SuccessMessage"] as string;
    ViewBag.Message = message;
    return View();
}

When to use

Simple success/error messages after a redirect.

Limitations

Only survives one redirect
Stores only simple types (strings, ints)
Requires session or cookie configuration

// Required in Program.cs
builder.Services.AddSession();
app.UseSession();

Option 2: Route Parameters and Query Strings

Pass data in the URL itself.

// Pass as route parameter
return RedirectToAction("Confirm", "Orders", new { id = orderId });

[HttpGet("orders/confirm/{id}")]
public IActionResult Confirm(Guid id)
{
    var order = _orderService.GetById(id);
    return View(order);
}

Or as a query string:

return RedirectToAction("Index", "Dashboard", new { message = "Order created", orderId = id });

[HttpGet]
public IActionResult Index(string message, Guid orderId) { }

When to use

IDs, filters, page numbers — anything safe to expose in the URL and should be bookmarkable.

Limitations

Visible in the URL — do not pass sensitive data
Limited to simple types
Long query strings can hit browser URL length limits

Option 3: The Service Layer — The Recommended Approach

In well-architected ASP.NET Core applications, controllers should not communicate with each other at all.

They should both call the same service or query the same data.

// ❌ Anti-pattern: passing data controller-to-controller

// ✅ Correct: both controllers use the same service
public class OrderController : ControllerBase
{
    private readonly IOrderService _orderService;

    [HttpPost]
    public async Task<IActionResult> Create([FromBody] CreateOrderDto dto)
    {
        var orderId = await _orderService.CreateAsync(dto);
        return Ok(new { orderId });
    }
}

public class DashboardController : ControllerBase
{
    private readonly IOrderService _orderService;

    [HttpGet]
    public async Task<IActionResult> Index()
    {
        var recentOrders = await _orderService.GetRecentAsync();
        return Ok(recentOrders);
    }
}

Each controller gets what it needs from the service layer. No controller-to-controller dependency. No state passed between them.

Option 4: Session

Session stores data server-side, keyed to a session cookie.

// Store
HttpContext.Session.SetString("LastOrderId", orderId.ToString());
HttpContext.Session.SetString("UserMessage", "Order created");

// Retrieve
var lastOrderId = HttpContext.Session.GetString("LastOrderId");
var message = HttpContext.Session.GetString("UserMessage");

When to use

Multi-step wizards (shopping carts, multi-page forms) where state must persist across several requests.

Limitations

Stateful — complicates horizontal scaling (use Redis for distributed session)
Must manage session expiry and cleanup
Not suitable for REST APIs

Option 5: IMemoryCache

Cache data by a key and read it in the next action.

// Store after creating order
_cache.Set($"order-result-{userId}", new OrderResult(orderId, "Created"),
    TimeSpan.FromMinutes(5));

// Read in next action
var result = _cache.Get<OrderResult>($"order-result-{userId}");

When to use

When you need to pass richer objects across a redirect and TempData is too limited.

Comparison at a Glance

Approach	Survives	Stores	Use for
TempData	1 redirect	Simple types	Flash messages
Query string	Permanent (URL)	Simple types	IDs, filters
Service layer	N/A — preferred	Anything	Everything
Session	Duration of session	Simple types	Wizards, carts
IMemoryCache	Cache TTL	Any type	Rich transient state

Interview-Ready Summary

TempData = persists for exactly one redirect — good for flash messages
Query strings and route params = safe for IDs and filters, visible in URL
The service layer = the correct architectural answer — controllers share services, not state
Session = stateful, requires configuration, suited for multi-step flows
In REST APIs, controllers should be stateless — never pass state between them

A strong interview answer:

"In ASP.NET Core, TempData handles simple messages across a single redirect. Route and query parameters work for IDs and filters. But the correct architectural answer is the service layer — both controllers call the same service to get what they need, and no state is passed between controllers at all. In REST APIs, controllers should be stateless, with all shared state living in the database or cache, not in controller-level variables."

Background Services in .NET — IHostedService and BackgroundService Explained

Libin Tom Baby — Mon, 27 Apr 2026 14:00:00 +0000

IHostedService, BackgroundService, Worker Service, scoped services in background, Hangfire comparison

Not all work in a .NET application happens within an HTTP request.

Scheduled jobs, message queue consumers, cache warmers, health check pollers — these all run in the background, independently of the request pipeline.

IHostedService — The Foundation

IHostedService tells the .NET host: "run this when the application starts, stop it when the application stops."

public interface IHostedService
{
    Task StartAsync(CancellationToken cancellationToken);
    Task StopAsync(CancellationToken cancellationToken);
}

Basic implementation

public class StartupCacheWarmer : IHostedService
{
    private readonly IProductCache _cache;
    private readonly ILogger<StartupCacheWarmer> _logger;

    public StartupCacheWarmer(IProductCache cache, ILogger<StartupCacheWarmer> logger)
    {
        _cache = cache;
        _logger = logger;
    }

    public async Task StartAsync(CancellationToken ct)
    {
        _logger.LogInformation("Warming cache...");
        await _cache.LoadAsync(ct);
        _logger.LogInformation("Cache ready.");
    }

    public Task StopAsync(CancellationToken ct) => Task.CompletedTask;
}

// Register
builder.Services.AddHostedService<StartupCacheWarmer>();

BackgroundService — For Long-Running Work

BackgroundService is an abstract base class for long-running background tasks. Override ExecuteAsync.

public class OrderProcessor : BackgroundService
{
    private readonly ILogger<OrderProcessor> _logger;

    public OrderProcessor(ILogger<OrderProcessor> logger) => _logger = logger;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _logger.LogInformation("Order processor started.");

        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                await ProcessPendingOrdersAsync(stoppingToken);
                await Task.Delay(TimeSpan.FromSeconds(30), stoppingToken);
            }
            catch (OperationCanceledException)
            {
                // Graceful shutdown — expected
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "Error processing orders.");
                await Task.Delay(TimeSpan.FromSeconds(5), stoppingToken); // Back off
            }
        }

        _logger.LogInformation("Order processor stopped.");
    }

    private async Task ProcessPendingOrdersAsync(CancellationToken ct) { }
}

Using DI Inside Background Services

Background services are registered as singletons.

You cannot directly inject scoped services (like DbContext) into a singleton.

The solution: IServiceScopeFactory

public class ReportGenerator : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;

    public ReportGenerator(IServiceScopeFactory scopeFactory)
        => _scopeFactory = scopeFactory;

    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        while (!ct.IsCancellationRequested)
        {
            await GenerateReportsAsync(ct);
            await Task.Delay(TimeSpan.FromHours(1), ct);
        }
    }

    private async Task GenerateReportsAsync(CancellationToken ct)
    {
        // Create a new scope for each execution
        using var scope = _scopeFactory.CreateScope();
        var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        var emailService = scope.ServiceProvider.GetRequiredService<IEmailService>();

        var orders = await db.Orders.Where(o => !o.Reported).ToListAsync(ct);
        await emailService.SendReportAsync(orders);

        foreach (var order in orders) order.Reported = true;
        await db.SaveChangesAsync(ct);
    }
}

Create a new scope for each unit of work. The DbContext is properly scoped and disposed.

Consuming a Message Queue

public class OrderEventConsumer : BackgroundService
{
    private readonly IServiceBusClient _bus;
    private readonly IServiceScopeFactory _scopeFactory;

    public OrderEventConsumer(IServiceBusClient bus, IServiceScopeFactory scopeFactory)
    {
        _bus = bus;
        _scopeFactory = scopeFactory;
    }

    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        await foreach (var message in _bus.ReadMessagesAsync(ct))
        {
            using var scope = _scopeFactory.CreateScope();
            var handler = scope.ServiceProvider.GetRequiredService<IOrderEventHandler>();
            await handler.HandleAsync(message, ct);
        }
    }
}

When to Use Hangfire or Quartz.NET

BackgroundService is great for continuous loops and simple scheduling.

Hangfire

// One-off job
BackgroundJob.Enqueue(() => Console.WriteLine("Hello from background"));

// Recurring job
RecurringJob.AddOrUpdate("daily-report", () => SendDailyReport(), Cron.Daily);

Hangfire persists jobs to a database — jobs survive application restarts.

Quartz.NET

More powerful scheduling: cron expressions, job dependencies, misfire handling, clustering.

var trigger = TriggerBuilder.Create()
    .WithCronSchedule("0 0 8 * * ?") // Every day at 8am
    .Build();

Decision guide

Scenario	Use
Continuous loop (poll queue, process stream)	`BackgroundService`
Simple recurring task	`BackgroundService`
Scheduled jobs that survive restarts	Hangfire
Complex cron scheduling	Quartz.NET
Distributed job coordination	Hangfire or Quartz with clustering

Interview-Ready Summary

IHostedService = runs on app start, stops on app stop — good for one-off startup tasks
BackgroundService = abstract base for long-running loops — override ExecuteAsync
Always respect CancellationToken — check stoppingToken.IsCancellationRequested
Background services are singletons — never inject scoped services directly
Use IServiceScopeFactory to resolve scoped services within background work
Hangfire = persistent jobs, survive restarts, dashboard included
Quartz.NET = advanced cron scheduling, distributed clustering

A strong interview answer:

"BackgroundService is the built-in way to run long-running background work in .NET. You override ExecuteAsync and loop with a CancellationToken for graceful shutdown. The main gotcha is DI lifetime — background services are singletons, so you need IServiceScopeFactory to resolve scoped services like DbContext. For more complex scheduling needs — like jobs that survive restarts or complex cron expressions — Hangfire or Quartz.NET are better choices."

Global Exception Handling in ASP.NET Core — The Complete Guide

Libin Tom Baby — Sat, 25 Apr 2026 14:00:00 +0000

UseExceptionHandler, IExceptionHandler (.NET 8), ProblemDetails, middleware vs filters, logging errors

Unhandled exceptions are inevitable.

The question is not whether they will happen — it's whether your API returns a clear, structured error response or exposes a raw stack trace to the client.

Why You Need Global Exception Handling

Without it:

Unhandled exceptions return 500 Internal Server Error with no useful body
Stack traces may be leaked to clients in non-production environments
Logging is inconsistent — some exceptions get logged, others disappear
Every controller has its own try-catch — duplicated and inconsistent

With it:

Every unhandled exception is caught in one place
Errors are logged consistently
Clients receive a structured, predictable error response
Controllers stay clean — no try-catch everywhere

Approach 1: `UseExceptionHandler` Middleware

The simplest and most compatible approach. Works in all ASP.NET Core versions.

app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var error = context.Features.Get<IExceptionHandlerFeature>();
        var exception = error?.Error;

        context.Response.StatusCode = exception switch
        {
            NotFoundException => StatusCodes.Status404NotFound,
            ValidationException => StatusCodes.Status400BadRequest,
            UnauthorizedException => StatusCodes.Status401Unauthorized,
            _ => StatusCodes.Status500InternalServerError
        };

        context.Response.ContentType = "application/problem+json";

        var problem = new ProblemDetails
        {
            Status = context.Response.StatusCode,
            Title = GetTitle(exception),
            Detail = exception?.Message,
            Instance = context.Request.Path
        };

        await context.Response.WriteAsJsonAsync(problem);
    });
});

Approach 2: `IExceptionHandler` (.NET 8+)

The modern approach — typed handlers that can be chained.

public class ValidationExceptionHandler : IExceptionHandler
{
    private readonly ILogger<ValidationExceptionHandler> _logger;

    public ValidationExceptionHandler(ILogger<ValidationExceptionHandler> logger)
        => _logger = logger;

    public async ValueTask<bool> TryHandleAsync(
        HttpContext context,
        Exception exception,
        CancellationToken ct)
    {
        if (exception is not ValidationException validationEx)
            return false; // Pass to next handler

        _logger.LogWarning("Validation failed: {Errors}", validationEx.Errors);

        context.Response.StatusCode = StatusCodes.Status400BadRequest;

        var problem = new ValidationProblemDetails(validationEx.ToDictionary())
        {
            Status = StatusCodes.Status400BadRequest,
            Title = "Validation failed",
            Instance = context.Request.Path
        };

        await context.Response.WriteAsJsonAsync(problem, ct);

        return true; // Handled — stop processing
    }
}

builder.Services.AddExceptionHandler<ValidationExceptionHandler>();
builder.Services.AddExceptionHandler<NotFoundExceptionHandler>();
builder.Services.AddExceptionHandler<GlobalExceptionHandler>(); // catch-all last

builder.Services.AddProblemDetails();

app.UseExceptionHandler();

Approach 3: Exception Filter (MVC only)

For MVC controllers specifically — not minimal APIs.

public class ApiExceptionFilter : IExceptionFilter
{
    private readonly ILogger<ApiExceptionFilter> _logger;

    public ApiExceptionFilter(ILogger<ApiExceptionFilter> logger)
        => _logger = logger;

    public void OnException(ExceptionContext context)
    {
        _logger.LogError(context.Exception, "Unhandled exception");

        context.Result = context.Exception switch
        {
            NotFoundException ex => new NotFoundObjectResult(ex.Message),
            ValidationException ex => new BadRequestObjectResult(ex.Message),
            _ => new ObjectResult("An error occurred")
                { StatusCode = StatusCodes.Status500InternalServerError }
        };

        context.ExceptionHandled = true;
    }
}

// Register globally
builder.Services.AddControllers(options =>
{
    options.Filters.Add<ApiExceptionFilter>();
});

ProblemDetails — RFC 7807

ProblemDetails is the standard structured error response format.

{
  "type": "https://tools.ietf.org/html/rfc7807",
  "title": "Validation failed",
  "status": 400,
  "detail": "The 'Name' field is required",
  "instance": "/api/orders",
  "traceId": "00-8a3e12b1c456d789-b23f4a12c3d45e67-00"
}

Enabling globally:

builder.Services.AddProblemDetails();

Custom Domain Exceptions

public abstract class DomainException : Exception
{
    protected DomainException(string message) : base(message) { }
}

public class NotFoundException : DomainException
{
    public NotFoundException(string entity, object key)
        : base($"{entity} with key {key} was not found.") { }
}

public class ValidationException : DomainException
{
    public IReadOnlyList<string> Errors { get; }

    public ValidationException(IEnumerable<string> errors)
        : base("One or more validation failures occurred.")
    {
        Errors = errors.ToList();
    }
}

public class UnauthorizedException : DomainException
{
    public UnauthorizedException() : base("Unauthorised.") { }
}

Throw them anywhere in your application code — the global handler catches and maps them.

Logging Exceptions

_logger.LogError(
    exception,
    "Unhandled exception for {Method} {Path} — TraceId: {TraceId}",
    context.Request.Method,
    context.Request.Path,
    Activity.Current?.Id ?? context.TraceIdentifier);

Interview-Ready Summary

UseExceptionHandler = catch-all middleware, compatible with all ASP.NET Core versions
IExceptionHandler (.NET 8+) = typed, chainable handlers — preferred for new projects
Exception filters = MVC-specific, controller-level
ProblemDetails = RFC 7807 standard for structured error responses
Define a domain exception hierarchy to map business errors to HTTP status codes
Log every exception with request context and a correlation/trace ID
Never expose raw stack traces to clients

A strong interview answer:

"In ASP.NET Core, global exception handling is best done with UseExceptionHandler middleware or the IExceptionHandler interface introduced in .NET 8. Both catch all unhandled exceptions in one place, log them, and return a structured ProblemDetails response. IExceptionHandler allows typed, chainable handlers where each handles a specific exception type. The key is to keep controllers free of try-catch blocks and let the global handler decide the HTTP status code."

Calling Stored Procedures in Entity Framework and Choosing the Right ORM Tool

Libin Tom Baby — Thu, 23 Apr 2026 14:00:00 +0000

FromSqlRaw, ExecuteSqlRaw, output params, Dapper vs EF Core, raw SQL, ORM comparison table

Entity Framework Core is the default ORM for .NET — but it's not the only option, and it's not always the right one.

This guide covers how to call stored procedures from EF Core (including output parameters), then compares the main ORM tools so you can choose the right one for your scenario.

Why Use Stored Procedures?

Stored procedures are pre-compiled SQL that runs server-side.

Use them when:

Complex business logic is already written in SQL by your DBA
Performance-critical queries benefit from a fixed execution plan
Security — stored procedures restrict direct table access
You're integrating with a legacy system with existing procedures

Calling Stored Procedures in EF Core

Method 1: `FromSqlRaw` — returns entities

Use when the stored procedure returns rows that map to an entity.

var orders = await dbContext.Orders
    .FromSqlRaw("EXEC GetOrdersByCustomer @CustomerId = {0}", customerId)
    .ToListAsync();

With explicit SqlParameter for safer parameterisation:

var param = new SqlParameter("@CustomerId", customerId);

var orders = await dbContext.Orders
    .FromSqlRaw("EXEC GetOrdersByCustomer @CustomerId", param)
    .ToListAsync();

Method 2: `SqlQueryRaw` — returns any type (.NET 7+)

Use when the stored procedure returns columns that don't map to an existing entity.

var summaries = await dbContext.Database
    .SqlQueryRaw<OrderSummaryDto>(
        "EXEC GetOrderSummaries @From, @To",
        new SqlParameter("@From", fromDate),
        new SqlParameter("@To", toDate))
    .ToListAsync();

Method 3: `ExecuteSqlRawAsync` — no return value

Use for INSERT, UPDATE, DELETE procedures that don't return rows.

await dbContext.Database.ExecuteSqlRawAsync(
    "EXEC ArchiveOldOrders @CutoffDate",
    new SqlParameter("@CutoffDate", cutoffDate));

Output Parameters

Output parameters require explicit SqlParameter setup.

var orderIdParam = new SqlParameter
{
    ParameterName = "@OrderId",
    SqlDbType = SqlDbType.UniqueIdentifier,
    Direction = ParameterDirection.Output
};

var statusParam = new SqlParameter
{
    ParameterName = "@Status",
    SqlDbType = SqlDbType.NVarChar,
    Size = 50,
    Direction = ParameterDirection.Output
};

await dbContext.Database.ExecuteSqlRawAsync(
    "EXEC CreateOrder @CustomerId, @Product, @OrderId OUTPUT, @Status OUTPUT",
    new SqlParameter("@CustomerId", customerId),
    new SqlParameter("@Product", product),
    orderIdParam,
    statusParam);

var newOrderId = (Guid)orderIdParam.Value;
var status = (string)statusParam.Value;

ORM Comparison — Choosing the Right Tool

Entity Framework Core

The full-featured ORM for .NET. Abstracts SQL for most operations.

var orders = await db.Orders
    .Where(o => o.CustomerId == id && o.Status == OrderStatus.Active)
    .Include(o => o.Lines)
    .OrderByDescending(o => o.CreatedAt)
    .Take(50)
    .AsNoTracking()
    .ToListAsync();

Use when: CRUD operations dominate, LINQ is preferred, rapid development matters, migrations are needed.

Avoid when: you need fine-grained SQL control or maximum performance on complex queries.

Dapper

A micro-ORM by the Stack Overflow team. Maps raw SQL results to objects.

using var connection = new SqlConnection(connectionString);

var orders = await connection.QueryAsync<Order>(
    "SELECT * FROM Orders WHERE CustomerId = @CustomerId AND Status = @Status",
    new { CustomerId = id, Status = "Active" });

Use when: maximum performance, full SQL control, simple mapping, or legacy databases where EF migrations don't fit.

Avoid when: you want LINQ queries, change tracking, or automatic migrations.

NHibernate

A mature, feature-rich ORM with a longer history than EF Core.

Use when: working with legacy enterprise systems that already use NHibernate, or when you need features like second-level caching out of the box.

Raw ADO.NET

No ORM — direct SQL via SqlConnection, SqlCommand, SqlDataReader.

using var conn = new SqlConnection(connectionString);
using var cmd = new SqlCommand("SELECT * FROM Orders WHERE Id = @Id", conn);
cmd.Parameters.AddWithValue("@Id", orderId);

await conn.OpenAsync();
using var reader = await cmd.ExecuteReaderAsync();

while (await reader.ReadAsync())
{
    // Map manually
}

Use when: absolute maximum performance, complex multi-resultset stored procedures, or bulk operations where EF Core overhead is unacceptable.

Side-by-Side Comparison

	EF Core	Dapper	NHibernate	ADO.NET
LINQ queries	✅	❌	✅	❌
Migrations	✅	❌	✅	❌
Change tracking	✅	❌	✅	❌
Raw SQL	✅	✅	✅	✅
Performance	Good	Excellent	Good	Maximum
Learning curve	Medium	Low	High	Low
Best for	General purpose	Performance	Legacy	Ultra-perf

Interview-Ready Summary

Use FromSqlRaw for stored procedures returning entities
Use SqlQueryRaw for stored procedures returning custom shapes (.NET 7+)
Use ExecuteSqlRawAsync for stored procedures with no return value
Output parameters require SqlParameter with ParameterDirection.Output
EF Core = full ORM, LINQ, migrations — best for most applications
Dapper = micro-ORM, raw SQL, maximum speed — best for complex queries
ADO.NET = maximum control and performance, most verbose

A strong interview answer:

"EF Core supports stored procedures via FromSqlRaw for returning entities, SqlQueryRaw for custom types, and ExecuteSqlRawAsync for non-query procedures. For ORM choice, EF Core is ideal for CRUD-heavy applications with migrations, while Dapper is preferred when you need raw SQL performance without the overhead of a full ORM. ADO.NET is the fallback for maximum control."

CQRS and the Mediator Pattern in .NET with MediatR

Libin Tom Baby — Tue, 21 Apr 2026 14:00:00 +0000

CQRS concept, IRequest, IRequestHandler, pipeline behaviors, MediatR setup, CQRS vs CRUD

CQRS and the Mediator pattern are two of the most widely used architectural patterns in modern .NET systems.

CQRS gives you the why — separate reads from writes.
MediatR gives you the how — a clean, decoupled way to dispatch commands and queries.

What Is CQRS?

CQRS stands for Command Query Responsibility Segregation.

Reads and writes are fundamentally different operations. Treat them differently.

Write operations → Commands (change state, return nothing or an ID)
Read operations  → Queries  (return data, change nothing)

Before CQRS

public class OrderService
{
    public async Task CreateOrder(CreateOrderDto dto) { }
    public async Task<Order> GetOrder(Guid id) { }
    public async Task<List<Order>> GetOrdersByUser(Guid userId) { }
    public async Task CancelOrder(Guid id) { }
    public async Task UpdateOrder(Guid id, UpdateOrderDto dto) { }
}

This service grows without limit. Every developer adds to it. It becomes untestable.

After CQRS

Commands: CreateOrderCommand, CancelOrderCommand, UpdateOrderCommand
Queries:  GetOrderQuery, GetOrdersByUserQuery

Each operation is its own class. Each has its own handler. They are independent.

What Is the Mediator Pattern?

The Mediator pattern reduces coupling by routing messages through a central mediator.

// ❌ Controller directly calls service — tightly coupled
var service = new OrderService(db, email, logger);
service.CreateOrder(dto);

// ✅ Controller sends a command — doesn't know who handles it
await _mediator.Send(new CreateOrderCommand(dto));

MediatR in Practice

Installation

dotnet add package MediatR
dotnet add package MediatR.Extensions.Microsoft.DependencyInjection

Registration

builder.Services.AddMediatR(cfg =>
    cfg.RegisterServicesFromAssembly(typeof(Program).Assembly));

Commands — Write Operations

Define the command

public record CreateOrderCommand(string CustomerId, string Product, int Quantity)
    : IRequest<Guid>;

Write the handler

public class CreateOrderCommandHandler : IRequestHandler<CreateOrderCommand, Guid>
{
    private readonly AppDbContext _db;
    private readonly IEmailService _email;

    public CreateOrderCommandHandler(AppDbContext db, IEmailService email)
    {
        _db = db;
        _email = email;
    }

    public async Task<Guid> Handle(CreateOrderCommand cmd, CancellationToken ct)
    {
        var order = new Order
        {
            Id = Guid.NewGuid(),
            CustomerId = cmd.CustomerId,
            Product = cmd.Product,
            Quantity = cmd.Quantity,
            Status = OrderStatus.Pending
        };

        _db.Orders.Add(order);
        await _db.SaveChangesAsync(ct);
        await _email.SendConfirmationAsync(order);

        return order.Id;
    }
}

Send from the controller

[HttpPost]
public async Task<IActionResult> Create([FromBody] CreateOrderCommand command)
{
    var id = await _mediator.Send(command);
    return CreatedAtAction(nameof(Get), new { id }, null);
}

Queries — Read Operations

Define the query

public record GetOrdersByUserQuery(string CustomerId) : IRequest<List<OrderDto>>;

Write the handler

public class GetOrdersByUserQueryHandler
    : IRequestHandler<GetOrdersByUserQuery, List<OrderDto>>
{
    private readonly AppDbContext _db;

    public GetOrdersByUserQueryHandler(AppDbContext db) => _db = db;

    public async Task<List<OrderDto>> Handle(
        GetOrdersByUserQuery query, CancellationToken ct)
    {
        return await _db.Orders
            .Where(o => o.CustomerId == query.CustomerId)
            .Select(o => new OrderDto(o.Id, o.Product, o.Status))
            .AsNoTracking()
            .ToListAsync(ct);
    }
}

Pipeline Behaviours — Cross-Cutting Concerns

Pipeline behaviours wrap every command or query — perfect for logging, validation, and caching.

public class LoggingBehaviour<TRequest, TResponse>
    : IPipelineBehavior<TRequest, TResponse>
{
    private readonly ILogger<LoggingBehaviour<TRequest, TResponse>> _logger;

    public LoggingBehaviour(ILogger<LoggingBehaviour<TRequest, TResponse>> logger)
        => _logger = logger;

    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken ct)
    {
        _logger.LogInformation("Handling {Request}", typeof(TRequest).Name);
        var response = await next();
        _logger.LogInformation("Handled {Request}", typeof(TRequest).Name);
        return response;
    }
}

// Register
builder.Services.AddTransient(typeof(IPipelineBehavior<,>), typeof(LoggingBehaviour<,>));

Validation with FluentValidation

public class CreateOrderCommandValidator : AbstractValidator<CreateOrderCommand>
{
    public CreateOrderCommandValidator()
    {
        RuleFor(x => x.CustomerId).NotEmpty();
        RuleFor(x => x.Quantity).GreaterThan(0);
    }
}

public class ValidationBehaviour<TRequest, TResponse>
    : IPipelineBehavior<TRequest, TResponse>
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehaviour(IEnumerable<IValidator<TRequest>> validators)
        => _validators = validators;

    public async Task<TResponse> Handle(
        TRequest request,
        RequestHandlerDelegate<TResponse> next,
        CancellationToken ct)
    {
        var failures = _validators
            .Select(v => v.Validate(request))
            .SelectMany(r => r.Errors)
            .Where(e => e != null)
            .ToList();

        if (failures.Any())
            throw new ValidationException(failures);

        return await next();
    }
}

Interview-Ready Summary

CQRS separates reads (queries) from writes (commands)
The Mediator pattern routes messages through a central dispatcher — removing direct dependencies
MediatR is the standard .NET implementation of the Mediator pattern
Commands = write operations, implement IRequest<T>
Queries = read operations, implement IRequest<T>
Handlers implement IRequestHandler<TRequest, TResponse>
Pipeline behaviours add cross-cutting concerns: logging, validation, caching
Controllers send commands/queries — they don't know who handles them

A strong interview answer:

"CQRS separates reads and writes into distinct objects — Commands mutate state, Queries return data. MediatR implements the Mediator pattern by routing these objects to their handlers. This decouples controllers from services, makes each operation independently testable, and allows pipeline behaviours to wrap every request with logging, validation, or caching without any handler knowing about it."

Clean Architecture in .NET — A Practical, Real-World Guide

Libin Tom Baby — Sun, 19 Apr 2026 14:00:00 +0000

Layers (Domain/Application/Infrastructure/Presentation), dependency rules, folder structure, real project setup

Clean Architecture is one of the most talked-about patterns in enterprise .NET development.

But the theory is often dense and the examples either too simple or too complex to apply directly.

This guide breaks it down with a practical folder structure, real code examples, and clear rules for each layer.

The Core Idea

Clean Architecture organises your code into layers with one golden rule:

Dependencies only point inward.

The inner layers know nothing about the outer layers.

[Presentation]   → [Application] → [Domain]
[Infrastructure] → [Application] → [Domain]

Your business logic (Domain) has zero knowledge of databases, HTTP, or UI frameworks.

The Four Layers

1. Domain — the core

Contains your business entities, value objects, domain events, and interfaces.

No dependencies on any other layer. No NuGet packages for databases or HTTP.

// Domain/Entities/Order.cs
public class Order
{
    public Guid Id { get; private set; }
    public string CustomerId { get; private set; }
    public List<OrderLine> Lines { get; private set; } = new();
    public OrderStatus Status { get; private set; }

    public void AddLine(Product product, int quantity)
    {
        // Pure business logic — no EF, no HTTP
        if (quantity <= 0) throw new DomainException("Quantity must be positive");
        Lines.Add(new OrderLine(product, quantity));
    }
}

2. Application — use cases

Contains your use cases (CQRS commands and queries), interfaces for infrastructure, and application-level business logic.

Depends on Domain only.

// Application/Orders/Commands/CreateOrderCommand.cs
public record CreateOrderCommand(string CustomerId, List<OrderLineDto> Lines)
    : IRequest<Guid>;

public class CreateOrderCommandHandler : IRequestHandler<CreateOrderCommand, Guid>
{
    private readonly IOrderRepository _orders;
    private readonly IEmailService _email;

    public CreateOrderCommandHandler(IOrderRepository orders, IEmailService email)
    {
        _orders = orders;
        _email = email;
    }

    public async Task<Guid> Handle(CreateOrderCommand command, CancellationToken ct)
    {
        var order = Order.Create(command.CustomerId, command.Lines);
        await _orders.AddAsync(order, ct);
        await _email.SendOrderConfirmationAsync(order);
        return order.Id;
    }
}

3. Infrastructure — the outside world

Implements the interfaces defined in Application. Contains EF Core, HTTP clients, email services, file storage.

// Infrastructure/Persistence/OrderRepository.cs
public class OrderRepository : IOrderRepository
{
    private readonly AppDbContext _context;

    public OrderRepository(AppDbContext context) => _context = context;

    public async Task AddAsync(Order order, CancellationToken ct)
    {
        await _context.Orders.AddAsync(order, ct);
        await _context.SaveChangesAsync(ct);
    }
}

4. Presentation — the entry point

Controllers, minimal API endpoints, SignalR hubs. Receives HTTP requests and delegates to the Application layer.

// Presentation/Controllers/OrdersController.cs
[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    private readonly ISender _mediator;

    public OrdersController(ISender mediator) => _mediator = mediator;

    [HttpPost]
    public async Task<IActionResult> Create([FromBody] CreateOrderCommand command)
    {
        var id = await _mediator.Send(command);
        return CreatedAtAction(nameof(GetById), new { id }, null);
    }
}

Folder Structure

src/
├── MyApp.Domain/
│   ├── Entities/
│   ├── ValueObjects/
│   ├── Enums/
│   └── Exceptions/
├── MyApp.Application/
│   ├── Orders/
│   │   ├── Commands/
│   │   └── Queries/
│   ├── Interfaces/
│   └── Common/
├── MyApp.Infrastructure/
│   ├── Persistence/
│   ├── ExternalApis/
│   └── Services/
└── MyApp.Presentation/
    ├── Controllers/
    └── Program.cs

The Dependency Rule in Practice

Domain has no project references
Application references Domain only
Infrastructure references Application (to implement interfaces) and Domain
Presentation references Application — never Infrastructure directly

When to Use Clean Architecture

Use it when:

The system will grow over time
Multiple developers work on the codebase
Business logic is complex and must be tested independently
You expect to swap out infrastructure (database, external APIs)

Do not use it for small CRUD applications or prototypes — the overhead is not justified.

Interview-Ready Summary

Dependencies point inward — Domain knows nothing about Infrastructure
Domain = entities and pure business rules, no external dependencies
Application = use cases (CQRS commands/queries), defines interfaces
Infrastructure = implements interfaces, owns EF Core and external services
Presentation = controllers that delegate to Application via MediatR
Clean Architecture makes business logic testable without a database or HTTP stack

A strong interview answer:

"Clean Architecture separates the system into layers where dependencies only point inward. The Domain layer contains pure business logic with no external dependencies. Application defines use cases and interfaces. Infrastructure implements them. Presentation handles HTTP. This makes the business logic fully testable in isolation, and allows you to swap infrastructure — like switching databases — without touching your business rules."

What Happens Behind the Scenes When You Call an API in .NET

Libin Tom Baby — Fri, 17 Apr 2026 14:00:00 +0000

HttpClient lifecycle, DNS resolution, connection pooling, TLS handshake, request pipeline, response deserialization

You write await httpClient.GetAsync(url) and get a response back.

But what actually happens between those two moments?

This guide walks through every step — from DNS resolution to response deserialisation — explaining the mechanics that make HTTP calls work in .NET.

Step 1: HttpClient and IHttpClientFactory

HttpClient is the entry point for all outgoing HTTP calls in .NET.

The problem with `new HttpClient()`

// ❌ Never do this in a loop or per-request
using var client = new HttpClient();

Creating a new HttpClient per request:

Does not reuse TCP connections — expensive
Exhausts socket connections under load (socket exhaustion)
Ignores DNS changes (stale DNS)

The solution: IHttpClientFactory

// Register once
builder.Services.AddHttpClient("OrdersApi", client =>
{
    client.BaseAddress = new Uri("https://api.example.com");
    client.Timeout = TimeSpan.FromSeconds(30);
});

// Inject and use
public class OrderService
{
    private readonly HttpClient _client;

    public OrderService(IHttpClientFactory factory)
    {
        _client = factory.CreateClient("OrdersApi");
    }
}

IHttpClientFactory manages a pool of HttpMessageHandler instances, reusing connections safely while respecting DNS TTLs.

Step 2: DNS Resolution

Before a TCP connection can be established, the hostname must resolve to an IP address.

api.example.com → 104.21.45.22

Check the local DNS cache
If not cached, query the configured DNS server
DNS server responds with an IP address (and TTL)
Result is cached for the duration of the TTL

IHttpClientFactory rotates handlers on a schedule (default: 2 minutes) to pick up DNS changes and avoid stale IPs.

Step 3: TCP Connection

With the IP resolved, a TCP connection is established via the 3-way handshake.

Client → SYN      → Server
Client ← SYN-ACK  ← Server
Client → ACK       → Server
(Connection established)

SocketsHttpHandler (the default in .NET 5+) maintains a connection pool per host. Once established, connections are reused for subsequent requests (keep-alive), which dramatically reduces latency under load.

Step 4: TLS Handshake (HTTPS)

For HTTPS, a TLS handshake occurs after TCP.

Client sends ClientHello with supported cipher suites
Server responds with certificate and chosen cipher
Client verifies the certificate against trusted CAs
Keys are exchanged; the session is encrypted

TLS session resumption and HTTP/2 multiplexing reduce this overhead on subsequent requests.

Step 5: HTTP Request

With the connection established and encrypted, the HTTP request is sent.

GET /orders HTTP/2
Host: api.example.com
Authorization: Bearer eyJhbGci...
Accept: application/json

HTTP/1.1 vs HTTP/2

HTTP/1.1 sends requests sequentially per connection.
HTTP/2 multiplexes multiple requests over a single connection — significantly more efficient for APIs making many concurrent calls.

var handler = new SocketsHttpHandler
{
    EnableMultipleHttp2Connections = true
};

Step 6: The Response

The server processes the request and returns a response.

HTTP/2 200 OK
Content-Type: application/json

{ "orders": [...] }

Deserialisation in .NET

var response = await httpClient.GetAsync(url);
response.EnsureSuccessStatusCode();

var orders = await response.Content.ReadFromJsonAsync<List<Order>>();

ReadFromJsonAsync uses System.Text.Json — fast, low-allocation JSON deserialisation built into .NET.

Retry Policies with Polly

Real-world APIs fail. Transient failures (timeouts, 503s) should be retried.

builder.Services.AddHttpClient("OrdersApi")
    .AddTransientHttpErrorPolicy(policy =>
        policy.WaitAndRetryAsync(3, attempt =>
            TimeSpan.FromMilliseconds(200 * attempt)));

Polly integrates directly with IHttpClientFactory — retry, circuit breaker, timeout, and fallback policies are all configurable.

Interview-Ready Summary

HttpClient should be created via IHttpClientFactory — never new HttpClient() per request
DNS resolution maps hostname to IP; IHttpClientFactory rotates handlers to avoid stale DNS
TCP 3-way handshake establishes the connection
TLS handshake encrypts the connection (HTTPS)
HTTP/2 multiplexes multiple requests over one connection
ReadFromJsonAsync deserialises the response using System.Text.Json
Use Polly for retry policies on transient failures

A strong interview answer:

"Calling an API in .NET goes through DNS resolution, a TCP handshake, a TLS handshake for HTTPS, and then the HTTP request over an established connection. IHttpClientFactory manages connection pooling and handler rotation to avoid socket exhaustion and stale DNS. On the response side, System.Text.Json handles deserialisation. Polly adds retry and circuit breaker policies for resilience."

How Dependency Injection Works Internally in .NET

Libin Tom Baby — Wed, 15 Apr 2026 14:00:00 +0000

ServiceCollection, IServiceProvider, resolution chain, scope factory, how the container builds the object graph

Every ASP.NET Core application uses dependency injection.

But most developers only know how to use it — not how the container actually works under the hood.

This guide explains the mechanics: how services are registered, how the container resolves them, how lifetimes are enforced, and the mistakes that silently break things.

The Three Building Blocks

1. `IServiceCollection` — the registration

IServiceCollection is just a list. When you call AddScoped<T>(), you're adding a ServiceDescriptor to that list.

builder.Services.AddSingleton<ILogger, Logger>();
builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddTransient<IEmailService, EmailService>();

Nothing is created yet. You're just declaring what to build.

2. `IServiceProvider` — the container

When .Build() is called, the IServiceCollection is compiled into an IServiceProvider — the actual DI container.

var app = builder.Build(); // IServiceProvider is created here

3. Resolution — how objects are constructed

When a service is requested, the container:

Looks up the registered ServiceDescriptor
Checks if an existing instance should be returned (singleton/scoped)
If not, creates a new instance using the registered constructor
Resolves all constructor dependencies recursively
Returns the fully-constructed object

The Three Lifetimes — Explained Internally

Singleton

builder.Services.AddSingleton<IConfigService, ConfigService>();

One instance created on first request. Stored in the root container. Returned for every subsequent request — forever.

Use for: stateless services, configuration, caches, HTTP clients.

Scoped

builder.Services.AddScoped<IDbContext, AppDbContext>();

One instance per HTTP request. Created when the scope starts, disposed when it ends.

In ASP.NET Core, a new IServiceScope is created for each HTTP request. All scoped services within that request share the same instance.

Use for: database contexts, unit-of-work, per-request state.

Transient

builder.Services.AddTransient<IEmailService, EmailService>();

A new instance every single time the service is requested. No sharing.

Use for: lightweight, stateless services where a fresh instance is always needed.

How Constructor Injection Works

The container uses reflection to inspect the constructor.

public class OrderService
{
    private readonly IDbContext _db;
    private readonly IEmailService _email;
    private readonly ILogger<OrderService> _logger;

    public OrderService(
        IDbContext db,
        IEmailService email,
        ILogger<OrderService> logger)
    {
        _db = db;
        _email = email;
        _logger = logger;
    }
}

When IOrderService is requested, the container:

Finds OrderService as the implementation
Inspects its constructor via reflection
Resolves IDbContext, IEmailService, and ILogger<OrderService> recursively
Creates the OrderService instance with all dependencies injected

If any dependency is not registered, an InvalidOperationException is thrown at resolution time.

The Captive Dependency Problem

The most dangerous lifetime mistake.

A singleton depending on a scoped service:

// ❌ Captive dependency — runtime exception or silent bug
public class ReportService // Singleton
{
    public ReportService(IDbContext db) { } // IDbContext is Scoped
}

A singleton lives forever. A scoped service is tied to a request. The scoped service is never released — it becomes effectively a singleton with incorrect state.

ASP.NET Core detects this in Development mode. Enable it explicitly in Production:

builder.Host.UseDefaultServiceProvider(options =>
{
    options.ValidateScopes = true;
    options.ValidateOnBuild = true;
});

Resolving Services Manually

// From IServiceProvider directly
var service = app.Services.GetRequiredService<IMyService>();

// Creating a scope manually (e.g. in a background service)
using var scope = app.Services.CreateScope();
var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
await db.SaveChangesAsync();

Never resolve scoped services from the root IServiceProvider — they won't be disposed correctly. Always create a scope first.

Interview-Ready Summary

IServiceCollection is just a list of descriptors — nothing is created at registration
IServiceProvider is the compiled container that resolves and creates objects
Resolution works by inspecting constructors via reflection and recursively resolving dependencies
Singleton = one instance forever; Scoped = one per request; Transient = always new
Captive dependency = singleton holding a scoped service — causes bugs or exceptions
Always use CreateScope() when resolving scoped services in background contexts
ValidateOnBuild = true catches registration errors at startup, not at runtime

A strong interview answer:

"The .NET DI container is built from IServiceCollection — a list of service registrations. At build time, it compiles into an IServiceProvider. When a service is requested, the container uses reflection to inspect the constructor, recursively resolves each dependency, respects lifetimes, and returns the fully constructed object. The main lifetime trap is the captive dependency — a singleton holding a scoped service, which prevents proper disposal."

The Middleware Pipeline in ASP.NET Core — How It Really Works

Libin Tom Baby — Mon, 13 Apr 2026 14:00:00 +0000

Use, Run, Map, short-circuit, ordering, custom middleware

Every HTTP request in ASP.NET Core passes through a pipeline of middleware components before reaching your controller.

Understanding this pipeline is essential — it's where logging, authentication, exception handling, CORS, routing, and response caching all live.

What Is Middleware?

Middleware is software assembled into a pipeline to handle requests and responses.

Each middleware component:

Receives the incoming HttpContext
Optionally does something with the request
Calls the next middleware in the chain
Optionally does something with the response on the way back

Request  → [Logging] → [Auth] → [CORS] → [Routing] → [Handler]
Response ← [Logging] ← [Auth] ← [CORS] ← [Routing] ← [Handler]

The Three Methods: Use, Run, Map

`Use` — calls the next component

app.Use(async (context, next) =>
{
    Console.WriteLine("Before next middleware");
    await next(context);
    Console.WriteLine("After next middleware");
});

`Run` — terminal, does NOT call next

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello — pipeline stops here");
});

`Map` — branches based on path

app.Map("/health", branch =>
{
    branch.Run(async context =>
    {
        await context.Response.WriteAsync("Healthy");
    });
});

Ordering Matters — A Lot

The order you register middleware is the order it runs.

app.UseExceptionHandler();    // 1 — catch all unhandled exceptions first
app.UseHttpsRedirection();    // 2
app.UseCors();                // 3
app.UseAuthentication();      // 4 — who are you?
app.UseAuthorization();       // 5 — what can you do?
app.UseRateLimiter();         // 6
app.MapControllers();         // 7 — route to controller

Getting the order wrong causes real bugs. Authentication before exception handling means auth errors won't be caught cleanly.

Short-Circuiting the Pipeline

Middleware can stop the request from proceeding further.

app.Use(async (context, next) =>
{
    if (!context.Request.Headers.ContainsKey("X-API-Key"))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Missing API key");
        return; // ← Does NOT call next — pipeline stops here
    }

    await next(context);
});

This is how authentication middleware works — validate the token, let through or short-circuit with 401.

Building Custom Middleware

Inline (simple cases)

app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Custom-Header", "MyApp");
    await next(context);
});

Class-based (preferred for complex middleware)

public class RequestTimingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<RequestTimingMiddleware> _logger;

    public RequestTimingMiddleware(RequestDelegate next, ILogger<RequestTimingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var stopwatch = Stopwatch.StartNew();

        await _next(context);

        stopwatch.Stop();
        _logger.LogInformation(
            "Request {Method} {Path} completed in {ElapsedMs}ms",
            context.Request.Method,
            context.Request.Path,
            stopwatch.ElapsedMilliseconds);
    }
}

// Extension method
public static class RequestTimingMiddlewareExtensions
{
    public static IApplicationBuilder UseRequestTiming(this IApplicationBuilder app)
        => app.UseMiddleware<RequestTimingMiddleware>();
}

// Usage
app.UseRequestTiming();

Real-World Scenarios

Logging every request and response

app.Use(async (context, next) =>
{
    _logger.LogInformation("Incoming: {Method} {Path}",
        context.Request.Method, context.Request.Path);

    await next(context);

    _logger.LogInformation("Outgoing: {StatusCode}",
        context.Response.StatusCode);
});

Adding a correlation ID to every response

app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Correlation-Id", Guid.NewGuid().ToString());
    await next(context);
});

Interview-Ready Summary

Middleware forms a bidirectional pipeline — request goes in, response comes back
Use = calls next, Run = terminal, Map = branch by path
Order of registration = order of execution
Short-circuiting stops the pipeline — used by auth, rate limiting, validation
Custom middleware goes in a class implementing InvokeAsync(HttpContext)
Exception handling middleware should be first (outermost) so it catches everything

A strong interview answer:

"ASP.NET Core middleware forms a pipeline where each component can process the request before passing it to the next, and then process the response on the way back. The order matters — exception handling goes first, then CORS, then authentication, then routing. You can short-circuit the pipeline at any point, which is how auth middleware rejects unauthorised requests."

Threading vs Tasks vs Parallelism — The Complete .NET Concurrency Guide

Libin Tom Baby — Sat, 11 Apr 2026 14:00:00 +0000

Thread, ThreadPool, Task, Parallel.For, PLINQ, when to use each

Concurrency is one of the most misunderstood areas of .NET development.

Thread, Task, Parallel, async/await — developers often use these interchangeably without understanding what they actually do. The wrong choice costs you performance, correctness, and scalability.

This guide breaks down each concept clearly, with real-world guidance on when to use which.

⚠️ Note: Another post Async/Await in C# — A Deep Dive Into How Asynchronous Programming Really Works covers the difference between asynchrony and parallelism briefly. This post goes much deeper into the underlying primitives — Thread, ThreadPool, Task, and Parallel.

The Mental Model

Before the code, get the mental model right.

Concurrency — dealing with multiple things at once (managing)
Parallelism — doing multiple things at once (executing)
Asynchrony — starting something and doing other work while waiting

These are not the same thing.

Thread — The Low-Level Primitive

A Thread is an OS-level execution unit.

var thread = new Thread(() =>
{
    Console.WriteLine($"Running on thread {Thread.CurrentThread.ManagedThreadId}");
});

thread.Start();
thread.Join(); // Wait for it to finish

What you get

Full control over the thread lifecycle
Can set priority, name, apartment state
Can be a foreground or background thread

What it costs

Creating a thread allocates ~1MB of stack memory
OS scheduling overhead on every context switch
You are responsible for lifecycle management
Does not integrate with async/await

When to use Thread directly

Almost never in modern .NET. Use Task instead.

The only remaining valid use case is COM interop requiring a specific apartment state (STA thread for WinForms/WPF dialogs).

ThreadPool — Reusing Threads

The ThreadPool manages a pool of pre-created threads that can be reused.

ThreadPool.QueueUserWorkItem(_ =>
{
    Console.WriteLine("Running on a pool thread");
});

You don't create threads — you submit work items and the pool decides which thread handles it.

Why this matters

No thread creation overhead
Threads are reused across work items
The runtime tunes the pool size automatically

When to use ThreadPool directly

You don't. Task.Run() wraps ThreadPool and gives you a much better API.

Task — The Modern Standard

Task is the recommended abstraction for concurrent and asynchronous work in .NET.

// CPU-bound work on the ThreadPool
var task = Task.Run(() =>
{
    return ExpensiveCalculation();
});

var result = await task;

Task represents a promise

A Task is a promise that work will complete at some point.

Task — work with no return value
Task<T> — work that returns a value
ValueTask<T> — lightweight Task for high-frequency paths

Combining Tasks

// Run two tasks in parallel and wait for both
var t1 = Task.Run(() => DoWork1());
var t2 = Task.Run(() => DoWork2());

await Task.WhenAll(t1, t2);

// Wait for the first one to finish
var winner = await Task.WhenAny(t1, t2);

async/await — Asynchrony Without Blocking

async/await is not about parallelism.

It is about freeing threads while waiting for I/O — network calls, database queries, file reads.

// The thread is released while waiting for the HTTP response
var response = await httpClient.GetAsync(url);

The critical distinction

Scenario	Use
Waiting for a database query	`async`/`await`
Waiting for an HTTP call	`async`/`await`
Running a heavy calculation	`Task.Run()`
Running multiple calculations at once	`Parallel.For` / `Task.WhenAll`

Parallel — True CPU Parallelism

Parallel splits work across multiple CPU cores simultaneously.

Parallel.For

Parallel.For(0, 1000, i =>
{
    ProcessItem(i);
});

Parallel.ForEach

var items = GetLargeCollection();

Parallel.ForEach(items, item =>
{
    Process(item);
});

PLINQ

var results = items
    .AsParallel()
    .Where(x => x.IsValid)
    .Select(x => Transform(x))
    .ToList();

When to use Parallel

Only for CPU-bound work that can be split into independent chunks.

Never use Parallel for I/O-bound work — it wastes threads and can cause thread starvation.

The Decision Framework

Is the work CPU-bound or I/O-bound?
│
├── I/O-bound (network, DB, file)
│   └── Use async/await
│       └── Task.Run is NOT needed here
│
└── CPU-bound (calculations, image processing)
    │
    ├── Single heavy operation
    │   └── Task.Run(() => HeavyWork())
    │
    └── Many independent items
        └── Parallel.For / Parallel.ForEach / PLINQ

Common Mistakes

Mistake 1: Using Task.Run for I/O-bound work

// ❌ Wrong — wastes a thread waiting for I/O
var result = await Task.Run(() => httpClient.GetAsync(url));

// ✅ Correct — no thread needed while waiting
var result = await httpClient.GetAsync(url);

Mistake 2: Using async/await for CPU-bound work

// ❌ Looks async but blocks the thread
public async Task<int> ComputeAsync()
{
    return HeavyCpuWork(); // No await — just pretending to be async
}

// ✅ Correct — offload to ThreadPool
public async Task<int> ComputeAsync()
{
    return await Task.Run(() => HeavyCpuWork());
}

Mistake 3: Parallel for I/O

// ❌ This spawns threads and blocks them all waiting for HTTP
Parallel.ForEach(urls, url =>
{
    var result = httpClient.GetAsync(url).Result; // Blocking!
});

// ✅ Use Task.WhenAll for parallel async I/O
var tasks = urls.Select(url => httpClient.GetAsync(url));
var results = await Task.WhenAll(tasks);

Interview-Ready Summary

Thread is the OS-level primitive — powerful but expensive and rarely needed directly
ThreadPool recycles threads — Task.Run wraps it
Task is the standard abstraction for concurrent work
async/await frees threads during I/O — it is not parallelism
Parallel.For / Parallel.ForEach distributes CPU work across cores
I/O-bound → async/await; CPU-bound single op → Task.Run; CPU-bound many items → Parallel
Never use Parallel for I/O — it wastes threads

A strong interview answer:

"Threads are the OS-level unit of execution — expensive to create. Tasks abstract over the ThreadPool and support async/await. Async/await is about freeing threads during I/O, not parallelism. Parallelism means actually executing work on multiple cores simultaneously — that's what Parallel.For and Task.WhenAll are for. The golden rule: async/await for I/O-bound, Parallel or Task.Run for CPU-bound."

IAsyncEnumerable Explained — Async Streams in .NET

Libin Tom Baby — Thu, 09 Apr 2026 14:00:00 +0000

IAsyncEnumerable, yield return, cancellation tokens, vs IEnumerable, real-world streaming

Most developers know IEnumerable<T> and async/await.

IEnumerable<T> — lets you iterate a sequence.

async/await — lets you do I/O without blocking threads.

But IAsyncEnumerable<T> — introduced in C# 8 — combines both, and it solves a problem that neither alone handles well.

It lets you iterate a sequence asynchronously — yielding items one at a time as they become available, without loading everything into memory first.

The Problem They Solve

Imagine reading 100,000 records from a database and returning them to the caller.

Option 1: Return everything at once

public async Task<List<Order>> GetAllOrdersAsync()
{
    return await db.Orders.ToListAsync(); // ❌ Loads everything into memory
}

Memory spikes. The caller waits for the entire load.

Option 2: Synchronous yield

public IEnumerable<Order> GetAllOrders()
{
    foreach (var order in db.Orders) // ❌ Blocks the thread
        yield return order;
}

Streams items one at a time, but blocks the thread on every read.

Option 3: IAsyncEnumerable — the right way

public async IAsyncEnumerable<Order> GetAllOrdersAsync()
{
    await foreach (var order in db.Orders.AsAsyncEnumerable())
        yield return order; // ✅ Non-blocking, streamed one at a time
}

Items are produced and consumed one at a time, without blocking the thread, without loading everything into memory.

How It Works

IAsyncEnumerable<T> is the async version of IEnumerable<T>.

How to Produce an Async Stream

Use async, return IAsyncEnumerable<T>, and yield return each item.

// Producer
public async IAsyncEnumerable<int> GenerateNumbersAsync()
{
    for (int i = 0; i < 10; i++)
    {
        await Task.Delay(100); // Simulates async work
        yield return i;
    }
}

The producer can await before yielding each item. Each call to yield return sends one item to the consumer, then pauses until the consumer requests the next one.

How to Consume an Async Stream

The consumer uses await foreach.

// Consumer
await foreach (var number in GenerateNumbersAsync())
{
    Console.WriteLine(number);
}

This is the async equivalent of foreach.

Each iteration awaits the next item without blocking the thread.

Cancellation Support

Always support cancellation in long-running async streams.

Producer with cancellation

public async IAsyncEnumerable<Order> GetOrdersAsync(
    [EnumeratorCancellation] CancellationToken ct = default)
{
    await foreach (var order in db.Orders.AsAsyncEnumerable().WithCancellation(ct))
    {
        yield return order;
    }
}

Consumer with cancellation

using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(30));

await foreach (var order in GetOrdersAsync().WithCancellation(cts.Token))
{
    Process(order);
}

Without cancellation, a long-running stream can run indefinitely.

IAsyncEnumerable vs IEnumerable

	`IEnumerable<T>`	`IAsyncEnumerable<T>`
Execution	Synchronous	Asynchronous
Thread blocking	Yes	No
Use case	In-memory data	I/O-bound data sources
Iteration	`foreach`	`await foreach`
Cancellation	No	Yes (CancellationToken)
Memory	Can load all at once	Streams item by item

IAsyncEnumerable vs Task<List<T>>

	`Task<List<T>>`	`IAsyncEnumerable<T>`
Returns	All items at once	One at a time
Memory usage	High (all in memory)	Low (streaming)
Time to first item	After all items loaded	Immediately
Best for	Small datasets	Large or infinite streams

Real-World Scenarios

Scenario 1: Streaming database records

public async IAsyncEnumerable<Product> GetLowStockProductsAsync(
    [EnumeratorCancellation] CancellationToken ct = default)
{
    await foreach (var product in db.Products
        .Where(p => p.StockLevel < 10)
        .AsAsyncEnumerable()
        .WithCancellation(ct))
    {
        yield return product;
    }
}

Scenario 2: Streaming an external API

public async IAsyncEnumerable<WeatherReading> StreamWeatherAsync(
    [EnumeratorCancellation] CancellationToken ct = default)
{
    while (!ct.IsCancellationRequested)
    {
        var reading = await _weatherApi.GetLatestAsync(ct);
        yield return reading;
        await Task.Delay(1000, ct);
    }
}

Scenario 3: Reading a large file line by line

public async IAsyncEnumerable<string> ReadLinesAsync(
    string path,
    [EnumeratorCancellation] CancellationToken ct = default)
{
    await foreach (var line in File.ReadLinesAsync(path, ct))
    {
        yield return line;
    }
}

Scenario 4: Exposing async streams from an API endpoint (ASP.NET Core)

[HttpGet("stream")]
public async IAsyncEnumerable<Order> StreamOrders(
    [EnumeratorCancellation] CancellationToken ct)
{
    await foreach (var order in _service.GetOrdersAsync(ct))
    {
        yield return order;
    }
}

ASP.NET Core supports returning IAsyncEnumerable<T> directly from action methods.

Interview-Ready Summary

IAsyncEnumerable<T> lets you stream data asynchronously — one item at a time
Use yield return in an async method returning IAsyncEnumerable<T> to produce a stream
Use await foreach to consume it
Always use [EnumeratorCancellation] CancellationToken in producers
Use .WithCancellation(ct) in consumers
Prefer IAsyncEnumerable<T> over Task<List<T>> when datasets are large, unbounded, or I/O-bound
ASP.NET Core can return IAsyncEnumerable<T> directly from controller actions

A strong interview answer:

"IAsyncEnumerable allows asynchronous iteration — yielding items one at a time as they're available, instead of loading everything into memory first. It's ideal for large database queries, external API streams, and file processing. You produce it with yield return in an async method, and consume it with await foreach."

⭐ Add-On — LINQ and IAsyncEnumerable

As of .NET 9, LINQ supports IAsyncEnumerable<T> natively.

// .NET 9+
var filtered = await GetOrdersAsync()
    .Where(o => o.Amount > 100)
    .Take(50)
    .ToListAsync();

Before .NET 9, you needed the System.Linq.Async NuGet package for this.
Now it's built in — making async streams a first-class citizen alongside standard LINQ.

Forem: Libin Tom Baby

Debugging Production and Performance Issues in .NET — A Practical Guide

Part 1: Debugging Production Issues

Structured Logging — Your First Line of Defence

Correlation IDs

Application Insights

Health Checks

Part 2: Debugging Performance Issues

The Dashboard Problem — Millions of Records

SQL Query Plans — Finding Slow Queries

BenchmarkDotNet — Measuring C# Performance

The N+1 Query Problem

Memory Profiling — Diagnosing Leaks

Interview-Ready Summary

How to Pass Data Between Controllers in ASP.NET Core

Why You Can't Just Use a Variable

Option 1: TempData

When to use

Limitations

Option 2: Route Parameters and Query Strings

When to use

Limitations

Option 3: The Service Layer — The Recommended Approach

Option 4: Session

When to use

Limitations

Option 5: IMemoryCache

When to use

Comparison at a Glance

Interview-Ready Summary

Background Services in .NET — IHostedService and BackgroundService Explained

IHostedService — The Foundation

Basic implementation

BackgroundService — For Long-Running Work

Using DI Inside Background Services

The solution: IServiceScopeFactory

Consuming a Message Queue

When to Use Hangfire or Quartz.NET

Hangfire

Quartz.NET

Decision guide

Interview-Ready Summary

Global Exception Handling in ASP.NET Core — The Complete Guide

Why You Need Global Exception Handling

Approach 1: UseExceptionHandler Middleware

Approach 2: IExceptionHandler (.NET 8+)

Approach 3: Exception Filter (MVC only)

ProblemDetails — RFC 7807

Custom Domain Exceptions

Logging Exceptions

Interview-Ready Summary

Calling Stored Procedures in Entity Framework and Choosing the Right ORM Tool

Why Use Stored Procedures?

Calling Stored Procedures in EF Core

Method 1: FromSqlRaw — returns entities

Method 2: SqlQueryRaw — returns any type (.NET 7+)

Method 3: ExecuteSqlRawAsync — no return value

Output Parameters

ORM Comparison — Choosing the Right Tool

Entity Framework Core

Dapper

NHibernate

Raw ADO.NET

Side-by-Side Comparison

Interview-Ready Summary

CQRS and the Mediator Pattern in .NET with MediatR

What Is CQRS?

Before CQRS

After CQRS

What Is the Mediator Pattern?

MediatR in Practice

Installation

Registration

Commands — Write Operations

Define the command

Write the handler

Send from the controller

Queries — Read Operations

Define the query

Write the handler

Approach 1: `UseExceptionHandler` Middleware

Approach 2: `IExceptionHandler` (.NET 8+)

Method 1: `FromSqlRaw` — returns entities

Method 2: `SqlQueryRaw` — returns any type (.NET 7+)

Method 3: `ExecuteSqlRawAsync` — no return value

The problem with `new HttpClient()`

1. `IServiceCollection` — the registration

2. `IServiceProvider` — the container

`Use` — calls the next component

`Run` — terminal, does NOT call next

`Map` — branches based on path