DEV Community: Manohari Jayachandran

C# Basics Day 2: Classes, Inheritance, Interfaces, Exceptions, Null Handling and File I/O, With Seven Practice Projects and a Library App

Manohari Jayachandran — Wed, 28 Oct 2026 16:11:24 +0000

Why this post exists

This is Day 2 of a six-day plan to learn C# deeply. Day 1 covered the language core: types, strings, control flow, methods and collections. Day 2 is where C# starts to feel like C#: you stop writing loose lines of code and start designing objects that protect their own data and safety nets that stop one bad input from taking the program down.

Day 2 covers seven concepts: classes and properties, static/readonly/const, inheritance and interfaces, enums/structs/records, exception handling, null handling, and file I/O. Each one has what it is, an analogy, a short example, a practice question and a complete solution with the reasons it is written that way. At the end, a capstone Library Management app pulls all of Days 1 and 2 together.

Try each practice question yourself before reading the solution. All code targets .NET 8 or later and uses top-level statements, so you can paste each solution into the Program.cs of a new console project (dotnet new console) and run it.

Concept 6: Classes, constructors, properties and access modifiers

What it is. A class is a template that describes some data and the behaviour that goes with it. An object is one thing built from that template. A constructor runs when the object is created and makes sure it starts out valid. A property is a controlled doorway to a piece of data: it looks like a field from outside, but it can validate or restrict access. Access modifiers (public, private, protected, internal) decide who is allowed to see what.

The analogy: an architect's blueprint and the houses built from it. The blueprint (class) is not a house; each house (object) has its own furniture (data). The constructor is the builder, who refuses to hand over a house without a roof. Access modifiers are the rooms: public is the front porch anyone can walk onto, private is the bedroom only the owner enters, protected is the family-only wing, internal is the gated neighbourhood (your own project). A property is the front desk: visitors do not walk into the filing room, they ask the desk, and the desk can check ID first.

var dog = new Dog("Rex", 3);
dog.Birthday();
Console.WriteLine(dog);                       // Rex is 4

var puppy = new Dog("Bit");                   // uses the second constructor
Console.WriteLine(puppy.Age);                 // 0

var cat = new Cat { Name = "Tom" };           // object initializer; Name is required
cat.Color = "black";
Console.WriteLine($"{cat.Name} is {cat.Color}");   // Tom is black

class Dog
{
    private int _age;                         // private field: hidden from other classes

    public string Name { get; }               // read-only after construction

    public int Age
    {
        get => _age;
        private set                           // only this class can change it
        {
            if (value < 0) throw new ArgumentOutOfRangeException(nameof(value), "Age cannot be negative.");
            _age = value;
        }
    }

    public Dog(string name, int age)
    {
        Name = name;
        Age = age;
    }

    public Dog(string name) : this(name, 0) { }   // constructor chaining

    public void Birthday() => Age++;

    public override string ToString() => $"{Name} is {Age}";
}

class Cat
{
    public required string Name { get; init; }    // must be set, and only during initialization
    public string Color { get; set; } = "grey";   // default value
}

Output:

Rex is 4
0
Tom is black

What is happening here:

private int _age is a field, hidden from every other class. Everything outside goes through the Age property.
{ get; } makes a property read-only after construction. { get; private set; } lets everyone read it but only the class itself change it.
A property's setter can validate. Here a negative age is rejected, so a Dog can never hold one.
: this(name, 0) chains one constructor to another so the setup logic lives in one place.
required plus init means the value must be supplied in the object initializer and cannot be changed afterwards. It is a lightweight way to demand data without a long constructor.
override ToString() controls what you see when the object is printed. Without it you get the type name.

Practice question 6: BankAccount

Create a BankAccount class with an owner and a balance. It needs a Deposit and a Withdraw method that validate their input, and the balance must be read-only from outside the class.

Solution

var account = new BankAccount("Asha", 100m);
account.Deposit(50m);
account.Withdraw(30m);
Console.WriteLine($"{account.Owner}: {account.Balance:F2}");

try { account.Withdraw(500m); }
catch (InvalidOperationException ex) { Console.WriteLine(ex.Message); }

try { account.Deposit(-5m); }
catch (ArgumentOutOfRangeException ex) { Console.WriteLine($"Rejected deposit, parameter: {ex.ParamName}"); }

try { _ = new BankAccount("   "); }
catch (ArgumentException ex) { Console.WriteLine($"Rejected account, parameter: {ex.ParamName}"); }

public class BankAccount
{
    public BankAccount(string owner, decimal openingBalance = 0m)
    {
        ArgumentException.ThrowIfNullOrWhiteSpace(owner);
        ArgumentOutOfRangeException.ThrowIfNegative(openingBalance);

        Owner = owner.Trim();
        Balance = openingBalance;
    }

    public string Owner { get; }

    public decimal Balance { get; private set; }

    public void Deposit(decimal amount)
    {
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(amount);
        Balance += amount;
    }

    public void Withdraw(decimal amount)
    {
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(amount);
        if (amount > Balance)
        {
            throw new InvalidOperationException(
                $"Insufficient funds: balance is {Balance:F2}, requested {amount:F2}.");
        }
        Balance -= amount;
    }
}

Output:

Asha: 120.00
Insufficient funds: balance is 120.00, requested 500.00.
Rejected deposit, parameter: amount
Rejected account, parameter: owner

Why this is the best way to write it:

The object is valid from its first line. The constructor rejects a blank owner or a negative opening balance, so an invalid BankAccount can never exist. That removes a whole category of "how did the balance get like this?" bugs.
Balance { get; private set; } is the heart of encapsulation. Anyone can read it, but the only code that can change it is Deposit and Withdraw, and both validate first. A public setter would let any caller write account.Balance = 1_000_000.
decimal, not double, because this is money (see Day 1).
The ThrowIf... helpers give one-line guards that throw the right exception type with the parameter name filled in, which is what you see in the output (amount, owner).
Two kinds of failure, two exception types. A bad argument (negative amount) is an ArgumentException family error: the caller made a programming mistake. Insufficient funds is an InvalidOperationException: the argument is fine, but the object's current state does not allow it. In concept 10 you will turn that second one into a custom exception.
Defaults on the constructor (openingBalance = 0m) avoid writing a second constructor for the common case.

Concept 7: static, readonly, const and encapsulation

What it is. Four keywords that answer the question "who owns this value, and when can it change?". const is fixed at compile time. readonly is assigned once, when the object is built. static belongs to the class itself, not to any one object. Encapsulation is the habit of hiding the inside of a class and exposing only safe operations.

The analogy: an apartment building. A static member is the notice board in the lobby: one board, shared by every resident. An instance member is the fridge in each apartment: everyone has their own. A const is a sign engraved into the wall: decided before the building opened. A readonly field is a sealed envelope: filled in once when the apartment is built, never opened again. Encapsulation is the car dashboard: you use the pedals and the wheel, not the fuel injectors.

var first = new Counter("first");
var second = new Counter("second");
first.Hit();
first.Hit();
second.Hit();

Console.WriteLine(first.Hits);          // 2   (instance: each object has its own)
Console.WriteLine(second.Hits);         // 1
Console.WriteLine(Counter.Total);       // 3   (static: one copy shared by the class)
Console.WriteLine(Counter.Prefix);      // ctr (const: baked in at compile time)
Console.WriteLine(first.Label);         // ctr-first

class Counter
{
    public const string Prefix = "ctr";             // const: compile-time constant, implicitly static
    public static int Total { get; private set; }   // static: belongs to the class, not an object
    private readonly string _name;                  // readonly: assigned once, in the constructor

    public int Hits { get; private set; }
    public string Label => $"{Prefix}-{_name}";

    public Counter(string name) => _name = name;

    public void Hit()
    {
        Hits++;
        Total++;
    }
}

Output:

2
1
3
ctr
ctr-first

What is happening here:

const values are baked in at compile time and are implicitly static. Only simple types (numbers, bool, char, string) can be const.
readonly fields can hold any type and are assigned in the declaration or the constructor, never afterwards. Use it for anything that should not change after construction.
static members are reached through the type name (Counter.Total), not an object. A static class cannot be instantiated at all, which suits helpers.
Static state is shared by everything in the program, including every thread. It is convenient and dangerous: treat mutable static data with suspicion.
An immutable object has no way to change after construction. Operations on it return a new object, exactly like string does.

Practice question 7: IdGenerator and Money

Write an IdGenerator that hands out unique ids from a static counter. Then write an immutable Money class (amount plus currency) that can be added, compared and printed.

Solution

Console.WriteLine(IdGenerator.Next("ORD"));
Console.WriteLine(IdGenerator.Next("ORD"));
Console.WriteLine(IdGenerator.Next("INV"));

var price = new Money(19.99m, "USD");
var tax = new Money(1.60m, "USD");
Money total = price + tax;

Console.WriteLine(total);                                   // 21.59 USD
Console.WriteLine(price);                                   // 19.99 USD (unchanged)
Console.WriteLine(total == new Money(21.59m, "USD"));       // True

try { _ = price + new Money(1m, "EUR"); }
catch (InvalidOperationException ex) { Console.WriteLine(ex.Message); }

public static class IdGenerator
{
    private static int _last;

    public static string Next(string prefix = "ID") =>
        $"{prefix}-{Interlocked.Increment(ref _last):D4}";
}

public sealed class Money : IEquatable<Money>
{
    public decimal Amount { get; }
    public string Currency { get; }

    public Money(decimal amount, string currency)
    {
        ArgumentException.ThrowIfNullOrWhiteSpace(currency);

        Amount = Math.Round(amount, 2, MidpointRounding.AwayFromZero);
        Currency = currency.Trim().ToUpperInvariant();
    }

    public Money Add(Money other)
    {
        ArgumentNullException.ThrowIfNull(other);
        if (other.Currency != Currency)
        {
            throw new InvalidOperationException($"Cannot add {other.Currency} to {Currency}.");
        }
        return new Money(Amount + other.Amount, Currency);   // a NEW object; this one never changes
    }

    public static Money operator +(Money a, Money b) => a.Add(b);

    public bool Equals(Money? other) =>
        other is not null && Amount == other.Amount && Currency == other.Currency;

    public override bool Equals(object? obj) => Equals(obj as Money);

    public override int GetHashCode() => HashCode.Combine(Amount, Currency);

    public static bool operator ==(Money? a, Money? b) => a is null ? b is null : a.Equals(b);

    public static bool operator !=(Money? a, Money? b) => !(a == b);

    public override string ToString() => $"{Amount:F2} {Currency}";
}

Output:

ORD-0001
ORD-0002
INV-0003
21.59 USD
19.99 USD
True
Cannot add EUR to USD.

Why this is the best way to write it:

Interlocked.Increment makes the counter thread-safe: two threads asking at the same instant can never receive the same id. A plain _last++ is three steps (read, add, write) that can interleave. You will study this properly on Day 5; using the safe tool from the start costs nothing.
IdGenerator is a static class. It holds no per-object data, so there is nothing to instantiate. The compiler enforces that.
{counter:D4} pads to four digits so ids sort naturally (ORD-0001). Note that this one counter is shared across prefixes, which is why INV got 0003.
Money has get-only properties and no setters, so once built it never changes. Add returns a new Money, which is why price still prints 19.99 after the addition.
It rounds in the constructor. Normalising at the door means two values that are equal to the cent are always equal in the code, instead of failing a comparison over a stray fraction.
The currency check prevents a silent bug. Adding euros to dollars throws instead of quietly producing nonsense.
It implements IEquatable<Money>, overrides Equals and GetHashCode, and defines ==. Together they make Money work in == comparisons and as a dictionary key. Hand-writing this once shows you exactly what a record gives you for free in concept 9.
sealed stops anyone subclassing it and breaking the immutability promise.

Concept 8: Inheritance, polymorphism, abstract classes, virtual/override and interfaces

What it is. Inheritance lets a class build on another (class Dog : Animal), reusing and extending it. Polymorphism means code can work with the general type (Animal) and the correct specific behaviour runs automatically. An abstract class is a base class that cannot be instantiated and can demand that subclasses fill in certain members. virtual marks a member subclasses may replace, and override is how they do it. An interface is a contract listing what a type can do, with no implementation.

The analogy: job descriptions and licences. Animal is a job description every employee shares: has a name, can speak. An abstract class is a description with a blank section every hire must complete, such as "how do you speak?". virtual is a default duty a hire may do differently. Polymorphism is one remote control that works on any TV: you press the same button and each device responds in its own way. An interface is a driving licence: it is not a job, it is an ability, and anyone in any job can hold one. A class has only one parent but can hold as many licences as it likes.

Animal[] zoo = { new Dog("Rex"), new Cat("Tom"), new Bird("Tweety") };

foreach (Animal animal in zoo)
{
    Console.WriteLine(animal.Describe());      // the right override runs for each real type

    if (animal is IFlyer flyer)                // interfaces can be checked at runtime too
        flyer.Fly();
}

abstract class Animal
{
    protected Animal(string name) => Name = name;

    public string Name { get; }

    public abstract string Speak();            // no body: every subclass MUST provide one

    public virtual string Describe() => $"{Name} says {Speak()}";   // subclasses MAY override
}

class Dog : Animal
{
    public Dog(string name) : base(name) { }
    public override string Speak() => "Woof";
}

class Cat : Animal
{
    public Cat(string name) : base(name) { }
    public override string Speak() => "Meow";
    public override string Describe() => base.Describe() + " (and ignores you)";
}

interface IFlyer
{
    void Fly();
}

class Bird : Animal, IFlyer                    // one base class, any number of interfaces
{
    public Bird(string name) : base(name) { }
    public override string Speak() => "Tweet";
    public void Fly() => Console.WriteLine($"{Name} flaps away");
}

Output:

Rex says Woof
Tom says Meow (and ignores you)
Tweety says Tweet
Tweety flaps away

What is happening here:

abstract string Speak() has no body: the compiler refuses to compile any non-abstract subclass that forgets to provide one.
virtual gives a default that subclasses can keep (Dog) or replace with override (Cat). base.Describe() calls the parent's version so the subclass can extend it.
The loop only knows about Animal. Which Speak runs is decided at runtime by the real object's type. That is polymorphism.
Bird : Animal, IFlyer shows one base class plus an interface. animal is IFlyer flyer tests for the ability.
Rule of thumb: inherit for a true "is-a" relationship (a dog is an animal). Use an interface for a "can-do" ability that unrelated types might share.

Practice question 8: shapes

Model Shape with Circle, Rectangle and Triangle subclasses and an IPrintable interface. Put shapes of mixed types in one list and compute the total area.

Solution

List<Shape> shapes = [new Circle(2), new Rectangle(3, 4), new Triangle(6, 5)];

foreach (IPrintable printable in shapes)
{
    printable.Print();
}

Console.WriteLine($"Total area: {shapes.Sum(s => s.Area()):F2}");

try { _ = new Circle(-1); }
catch (ArgumentOutOfRangeException ex) { Console.WriteLine($"Rejected: {ex.ParamName}"); }

public interface IPrintable
{
    void Print();
}

public abstract class Shape : IPrintable
{
    public abstract string Name { get; }

    public abstract double Area();

    public virtual void Print() => Console.WriteLine($"{Name,-10} area = {Area():F2}");

    protected static double Positive(double value, string paramName)
    {
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(value, paramName);
        return value;
    }
}

public sealed class Circle : Shape
{
    private readonly double _radius;

    public Circle(double radius) => _radius = Positive(radius, nameof(radius));

    public override string Name => "Circle";
    public override double Area() => Math.PI * _radius * _radius;
}

public sealed class Rectangle : Shape
{
    private readonly double _width, _height;

    public Rectangle(double width, double height)
    {
        _width = Positive(width, nameof(width));
        _height = Positive(height, nameof(height));
    }

    public override string Name => "Rectangle";
    public override double Area() => _width * _height;
}

public sealed class Triangle : Shape
{
    private readonly double _base, _height;

    public Triangle(double @base, double height)
    {
        _base = Positive(@base, nameof(@base));
        _height = Positive(height, nameof(height));
    }

    public override string Name => "Triangle";
    public override double Area() => 0.5 * _base * _height;
}

Output:

Circle     area = 12.57
Rectangle  area = 12.00
Triangle   area = 15.00
Total area: 39.57
Rejected: radius

Why this is the best way to write it:

The calling code never mentions Circle, Rectangle or Triangle. It loops over Shape and calls Area(). Adding a Square later means writing one new class and changing nothing else.
No if (shape is Circle) ... else if ... chain. The area formula lives inside each class, next to the data it needs. That chain is the classic sign that polymorphism should have been used.
Area() is abstract, so forgetting it in a new shape is a compile error, not a runtime surprise.
Print() is virtual with a sensible default, so most shapes need no code of their own but any shape can still override it.
IPrintable is separate from Shape. Later, an Invoice that has nothing to do with shapes can also be IPrintable, and a single foreach (IPrintable p ...) handles both.
A shared Positive helper in the base class validates dimensions once, so a negative radius is rejected at construction, as the last output line shows.
Fields are readonly and classes are sealed. Shapes cannot change after construction, and nobody can subclass a leaf by accident.
double is right here (unlike money), because geometry produces irrational numbers such as Math.PI * r * r anyway.

Concept 9: Enums, structs and records

What it is. An enum is a named set of fixed choices (Pending, Paid, Shipped). A struct is a small value type: assigning it copies the data. A class is a reference type: assigning it copies only the pointer. A record is a class (or struct) designed for data, with value-based equality, a readable ToString() and a non-destructive copy (with) built in.

The analogy: an enum is a restaurant menu: you pick from the listed dishes, not anything you can imagine. A struct is a sticky note: photocopy it and you have two independent notes. A class is a key to a shared locker: copy the key and both keys open the same locker, so anything one person puts in is seen by the other. A record is a passport: two passports with identical details describe the same identity, and with is renewing the passport with exactly one detail changed.

OrderStatus status = OrderStatus.Shipped;
Console.WriteLine($"{status} = {(int)status}");                   // Shipped = 2

// A trap: Enum.TryParse accepts numbers that are not in the enum
Console.WriteLine(Enum.TryParse("99", out OrderStatus weird));    // True!
Console.WriteLine(Enum.IsDefined(weird));                         // False: always check this too

// Copy behaviour: struct copies the value, class copies the reference
var s1 = new BoxStruct { Value = 1 };
var s2 = s1;
s2.Value = 99;
Console.WriteLine($"struct: s1={s1.Value}, s2={s2.Value}");       // 1 and 99

var c1 = new BoxClass { Value = 1 };
var c2 = c1;
c2.Value = 99;
Console.WriteLine($"class:  c1={c1.Value}, c2={c2.Value}");       // 99 and 99

enum OrderStatus { Pending, Paid, Shipped, Delivered, Cancelled }

struct BoxStruct { public int Value; }

class BoxClass { public int Value; }

Output:

Shipped = 2
True
False
struct: s1=1, s2=99
class:  c1=99, c2=99

What is happening here:

An enum is an int underneath (Shipped = 2). Because of that, Enum.TryParse("99", ...) succeeds even though 99 is not a real status. Always follow it with Enum.IsDefined.
Changing the struct copy (s2) left s1 alone. Changing the class "copy" (c2) changed c1 too, because they are the same object.
Use a struct only for small, immutable, value-like things (a point, a coordinate, a colour). Default to a class.

Practice question 9: OrderStatus, Point and Person

Model an OrderStatus enum, a Point struct and a Person record, then compare their equality behaviour against an ordinary class.

Solution

// 1. Enum: a fixed set of named choices, with business rules built on top
Console.WriteLine($"Pending -> Paid:      {OrderRules.CanMove(OrderStatus.Pending, OrderStatus.Paid)}");
Console.WriteLine($"Delivered -> Pending: {OrderRules.CanMove(OrderStatus.Delivered, OrderStatus.Pending)}");

// 2. Struct: a small value, compared by content
var a = new Point(1, 2);
var b = new Point(1, 2);
Console.WriteLine($"struct: a == b is {a == b}, a.Equals(b) is {a.Equals(b)}");

// 3. Class: compared by reference unless you override equality
var c1 = new PersonClass("Asha", 30);
var c2 = new PersonClass("Asha", 30);
Console.WriteLine($"class:  c1 == c2 is {c1 == c2}");

// 4. Record: a class with value equality, ToString and 'with' built in
var r1 = new Person("Asha", 30);
var r2 = new Person("Asha", 30);
Console.WriteLine($"record: r1 == r2 is {r1 == r2}, same object: {ReferenceEquals(r1, r2)}");

Person older = r1 with { Age = 31 };    // non-destructive copy
Console.WriteLine(r1);
Console.WriteLine(older);

enum OrderStatus { Pending, Paid, Shipped, Delivered, Cancelled }

static class OrderRules
{
    public static bool CanMove(OrderStatus from, OrderStatus to) => (from, to) switch
    {
        (OrderStatus.Pending, OrderStatus.Paid) => true,
        (OrderStatus.Pending, OrderStatus.Cancelled) => true,
        (OrderStatus.Paid, OrderStatus.Shipped) => true,
        (OrderStatus.Paid, OrderStatus.Cancelled) => true,
        (OrderStatus.Shipped, OrderStatus.Delivered) => true,
        _ => false
    };
}

readonly struct Point : IEquatable<Point>
{
    public int X { get; }
    public int Y { get; }

    public Point(int x, int y) => (X, Y) = (x, y);

    public bool Equals(Point other) => X == other.X && Y == other.Y;
    public override bool Equals(object? obj) => obj is Point p && Equals(p);
    public override int GetHashCode() => HashCode.Combine(X, Y);
    public static bool operator ==(Point left, Point right) => left.Equals(right);
    public static bool operator !=(Point left, Point right) => !left.Equals(right);
}

class PersonClass
{
    public string Name { get; }
    public int Age { get; }
    public PersonClass(string name, int age) => (Name, Age) = (name, age);
}

record Person(string Name, int Age);

Output:

Pending -> Paid:      True
Delivered -> Pending: False
struct: a == b is True, a.Equals(b) is True
class:  c1 == c2 is False
record: r1 == r2 is True, same object: False
Person { Name = Asha, Age = 30 }
Person { Name = Asha, Age = 31 }

Why this is the best way to write it:

The enum is more than a list of names. OrderRules.CanMove uses a switch expression over a tuple to describe the legal transitions in one readable table. Anything not listed falls into _ => false, so a new status is blocked until you decide where it fits.
Point is a readonly struct. Mutable structs cause confusing bugs because you end up modifying copies. Making it readonly removes the problem.
IEquatable<Point> plus Equals, GetHashCode and == together keep the equality rules consistent. Implementing only == and forgetting GetHashCode breaks dictionaries and hash sets.
The plain class says False because by default a class compares references, not contents. Two PersonClass objects with identical data are different objects.
The record says True in one line (record Person(string Name, int Age);). You also get a readable ToString() and with for free, which is why records are the right default for data that just carries values.
A rule of thumb: record for data, class for things with behaviour and identity, struct for tiny values. For a point, readonly record struct Point(int X, int Y); gives you everything above in one line.

Concept 10: Exception handling: try/catch/finally, custom exceptions, throw vs throw ex

What it is. An exception is the runtime's way of saying "something went wrong that this code cannot handle here". try marks code that might fail, catch handles a specific failure, and finally runs no matter what. Custom exceptions are your own error types that carry meaning and data.

The analogy: a tightrope act. try is the walk across, catch is the safety net underneath, and finally is packing up the equipment whether the artist fell or not. A custom exception is a labelled alarm: "kitchen fire" is far more useful than a generic "alarm". And throw; versus throw ex; is the difference between forwarding a letter with its original postmark and re-posting it as if you had written it: with the second, nobody can tell where it really started.

try
{
    Withdraw(balance: 50m, amount: 80m);
}
catch (InsufficientFundsException ex)               // most specific catch first
{
    Console.WriteLine($"Short by {ex.Shortfall:F2}");
}
catch (Exception ex)                                // general fallback last
{
    Console.WriteLine($"Unexpected: {ex.Message}");
}
finally
{
    Console.WriteLine("finally always runs, even after a throw");
}

// 'throw;' keeps the original stack trace. 'throw ex;' resets it.
try { Outer(keepStack: true); }
catch (Exception ex) { Console.WriteLine($"throw;    still shows Inner: {ex.StackTrace!.Contains(nameof(Inner))}"); }

try { Outer(keepStack: false); }
catch (Exception ex) { Console.WriteLine($"throw ex; still shows Inner: {ex.StackTrace!.Contains(nameof(Inner))}"); }

static void Withdraw(decimal balance, decimal amount)
{
    if (amount > balance) throw new InsufficientFundsException(balance, amount);
}

static void Outer(bool keepStack)
{
    try { Inner(); }
    catch (Exception ex)
    {
        Console.WriteLine($"  (logging: {ex.Message})");
        if (keepStack) throw; else throw ex;
    }
}

static void Inner() => throw new InvalidOperationException("boom");

class InsufficientFundsException : Exception
{
    public decimal Balance { get; }
    public decimal Requested { get; }
    public decimal Shortfall => Requested - Balance;

    public InsufficientFundsException(decimal balance, decimal requested)
        : base($"Balance {balance:F2} is less than requested {requested:F2}.")
    {
        Balance = balance;
        Requested = requested;
    }
}

Output:

Short by 30.00
finally always runs, even after a throw
  (logging: boom)
throw;    still shows Inner: True
  (logging: boom)
throw ex; still shows Inner: False

What is happening here:

Catch blocks run top to bottom, so put the most specific first and the general Exception last. Only catch what you can actually handle.
finally runs after success, after a handled error and even after an unhandled one. It is the place for cleanup.
A custom exception derives from Exception, ends its name in Exception, and carries useful data as properties (Shortfall). The handler reacts to the data instead of parsing a message.
throw; keeps the original stack trace. throw ex; resets it, so the trace no longer shows Inner, where the failure really began. The compiler even warns about it (CA2200) when you build this code. That warning is correct.
Exceptions are for the unexpected. For things users get wrong all the time, use TryParse and return values, as you did on Day 1.

Practice question 10: safe calculator with custom exceptions and logging

Build a safe calculator that evaluates expressions like 12 / 4. Failures must raise custom exceptions in the style of InsufficientFundsException (carrying useful data), and every failure must be logged.

Solution

using System.Globalization;

string logPath = Path.Combine(Path.GetTempPath(), "calculator.log");
File.Delete(logPath);

string[] inputs =
{
    "12 + 8",
    "9 / 4",
    "7 / 0",
    "5 ^ 2",
    "hello + 1",
    "1 +",
    "2.5 * 4"
};

foreach (string input in inputs)
{
    try
    {
        Console.WriteLine($"{input} = {Calculate(input)}");
    }
    catch (CalculatorException ex)
    {
        Console.WriteLine($"{input} -> error: {ex.Message}");
        Log(ex);
    }
}

Console.WriteLine($"{File.ReadAllLines(logPath).Length} error(s) written to the log file.");

static double Calculate(string expression)
{
    string[] parts = expression.Split(' ', StringSplitOptions.RemoveEmptyEntries);
    if (parts.Length != 3)
    {
        throw new CalculatorException($"Expected 'number operator number' but got '{expression}'.");
    }

    if (!double.TryParse(parts[0], NumberStyles.Float, CultureInfo.InvariantCulture, out double left) ||
        !double.TryParse(parts[2], NumberStyles.Float, CultureInfo.InvariantCulture, out double right))
    {
        throw new CalculatorException("Both operands must be numbers.");
    }

    return parts[1] switch
    {
        "+" => left + right,
        "-" => left - right,
        "*" => left * right,
        "/" when right == 0 => throw new DivideByZeroCalculatorException(left),
        "/" => left / right,
        _ => throw new UnknownOperatorException(parts[1])
    };
}

void Log(Exception ex)
{
    string line = $"{DateTime.UtcNow:O} [{ex.GetType().Name}] {ex.Message}";
    File.AppendAllText(logPath, line + Environment.NewLine);
}

class CalculatorException : Exception
{
    public CalculatorException(string message) : base(message) { }
    public CalculatorException(string message, Exception inner) : base(message, inner) { }
}

class DivideByZeroCalculatorException : CalculatorException
{
    public double Dividend { get; }

    public DivideByZeroCalculatorException(double dividend)
        : base($"Cannot divide {dividend} by zero.") => Dividend = dividend;
}

class UnknownOperatorException : CalculatorException
{
    public string Operator { get; }

    public UnknownOperatorException(string op)
        : base($"Unknown operator '{op}'. Use + - * or /.") => Operator = op;
}

Output:

12 + 8 = 20
9 / 4 = 2.25
7 / 0 -> error: Cannot divide 7 by zero.
5 ^ 2 -> error: Unknown operator '^'. Use + - * or /.
hello + 1 -> error: Both operands must be numbers.
1 + -> error: Expected 'number operator number' but got '1 +'.
2.5 * 4 = 10
4 error(s) written to the log file.

Why this is the best way to write it:

A base CalculatorException with specific children lets the loop catch every calculator problem with one clause, while callers who care can still catch DivideByZeroCalculatorException alone.
The exceptions carry data (Dividend, Operator), exactly like InsufficientFundsException carries a shortfall. A handler can use the values without parsing text.
The divide-by-zero check is explicit on purpose. With double, 7 / 0 does not throw in C#: it quietly returns Infinity. If you rely on the runtime to complain, you get a wrong answer instead of an error.
A switch expression with when and throw expressions ("/" when right == 0 => throw ...) keeps every operator, including its failure case, in one table.
TryParse for the operands, so bad numbers become a friendly custom error without the cost of an internal FormatException.
Only CalculatorException is caught. If a genuine bug throws a NullReferenceException, it crashes loudly instead of being swallowed. An empty catch (Exception) is how bugs hide for months.
The logging lives in one Log method with a UTC ISO-8601 timestamp, so changing where logs go (a file today, a service later) is a one-place edit.
Calculate is a pure function: string in, number or exception out, with no printing. That keeps it easy to test.

Concept 11: Null handling: Nullable, nullable reference types, ?., ?? and ??=

What it is. null means "no value", and using it carelessly is the source of the most common runtime crash in .NET: NullReferenceException. Modern C# helps with nullable reference types: turn the feature on and the compiler tracks which variables may be null (string?) and which never should be (string). Nullable<T> (written int?) gives value types a "no value" state. Three operators make null easy to handle: ?. (null-conditional), ?? (null-coalescing) and ??= (null-coalescing assignment).

The analogy: a mailbox. null is "there is no mailbox at this address", which is different from an empty mailbox. The ?. operator is ringing the doorbell before you walk in: if nobody answers you stop politely instead of barging through the wall. ?? is "if nobody is home, leave the parcel with this neighbour instead". ??= is "put a default parcel in the box, but only if it is empty". int? is an integer that is allowed to answer "I do not know".

int? maybeCount = null;                         // Nullable<int>: a value type that can also be 'no value'
Console.WriteLine(maybeCount.HasValue);         // False
Console.WriteLine(maybeCount ?? -1);            // -1  (?? supplies a fallback)

string? nickname = null;                        // nullable reference type: the ? is a promise to check
Console.WriteLine(nickname?.Length);            // (blank) ?. stops and returns null instead of crashing
Console.WriteLine(nickname?.Length ?? 0);       // 0
nickname ??= "guest";                           // assign only if currently null
Console.WriteLine(nickname);                    // guest

string name = "Asha";                           // no ?: the compiler warns if you assign null to it
Console.WriteLine(name.Length);                 // 4

Output:

False
-1

0
guest
4

What is happening here:

nickname?.Length is null when nickname is null, instead of throwing. Chain as many as you need: a?.b?.c.
?? -1 provides a fallback when the left side is null. ??= assigns only when the variable is currently null.
With <Nullable>enable</Nullable> in the project, assigning null to a plain string produces a compiler warning. The ? on a type is a promise to check before using it.
Avoid the ! operator (name!). It silences the compiler without making the code safe. It is you saying "trust me", and the runtime will not.
Prefer is null and is not null over == null: they cannot be broken by an overloaded ==.

Practice question 11: GetUserCity

Write GetUserCity(User? user) that safely navigates a nested object graph (User, then Address, then City) and never throws, even when any link in the chain is missing.

Solution

User?[] users =
{
    new("Asha", new Address("Chicago", new Country("US"))),
    new("Ravi", new Address("  Mumbai  ", null)),
    new("Meena", new Address(null, new Country("IN"))),
    new("Dev", null),
    null
};

foreach (User? user in users)
{
    Console.WriteLine($"{user?.Name ?? "(no user)",-9} city: {GetUserCity(user),-8} country: {GetUserCountryCode(user)}");
}

static string GetUserCity(User? user)
{
    string? city = user?.Address?.City;
    return string.IsNullOrWhiteSpace(city) ? "Unknown" : city.Trim();
}

static string GetUserCountryCode(User? user) => user?.Address?.Country?.Code ?? "??";

record User(string Name, Address? Address);

record Address(string? City, Country? Country);

record Country(string Code);

Output:

Asha      city: Chicago  country: US
Ravi      city: Mumbai   country: ??
Meena     city: Unknown  country: IN
Dev       city: Unknown  country: ??
(no user) city: Unknown  country: ??

Why this is the best way to write it:

One ?. chain replaces four nested if statements. user?.Address?.City stops at the first null link and returns null for the whole expression.
The result is held in a string? variable and checked once. You do the null decision in one place instead of scattering it.
string.IsNullOrWhiteSpace covers three cases at once: null, empty and spaces only. That is why Meena (null city) and Ravi's padded " Mumbai " are both handled, with a Trim() for the padded one.
The parameter is User? and the return is a plain string. The signature itself documents that null users are accepted and that callers will never get null back, so they need no check of their own.
The model types use nullable members to say what is optional. Address? and Country? tell the reader, and the compiler, exactly which links can be missing.
It does not throw for a null user. Whether a missing user should be an error or just "Unknown" is a design decision. Here, a display helper should be forgiving. A method that needs a user should call ArgumentNullException.ThrowIfNull(user) instead.

Concept 12: File I/O basics: File, StreamReader/StreamWriter and Path

What it is. File I/O (input/output) is how a program keeps data after it closes. The File class has one-line helpers for common jobs. StreamReader and StreamWriter read and write a file piece by piece. Path builds and picks apart file paths safely.

The analogy: a filing cabinet. A Path is the address of a drawer. StreamWriter is a pen: if you forget to put the cap on (close the file), the ink dries and the last words never make it to the page. A using block is a pen that caps itself. Saving safely is like writing the new page on scrap paper first and swapping it into the folder only once it is complete, so a power cut can never leave a half-written page in the cabinet.

string folder = Path.Combine(Path.GetTempPath(), "day2-demo");
Directory.CreateDirectory(folder);                          // safe if it already exists
string path = Path.Combine(folder, "notes.txt");           // never glue paths with + "/"

File.WriteAllText(path, "first line\nsecond line\n");       // create or overwrite
File.AppendAllText(path, "third line\n");                   // add to the end

foreach (string line in File.ReadLines(path))               // streams one line at a time
    Console.WriteLine(line);

using (var writer = new StreamWriter(path))                 // using = closes the file for you
{
    writer.WriteLine("rewritten");
}

using (var reader = new StreamReader(path))
{
    Console.WriteLine(reader.ReadToEnd().Trim());
}

Console.WriteLine(File.Exists(path));                       // True
Console.WriteLine(Path.GetFileName(path));                  // notes.txt
Console.WriteLine(Path.GetExtension(path));                 // .txt
File.Delete(path);

Output:

first line
second line
third line
rewritten
True
notes.txt
.txt

What is happening here:

Path.Combine joins parts with the right separator for the operating system. Never build paths with + "/" +.
File.WriteAllText creates or overwrites, File.AppendAllText adds to the end. File.ReadLines streams one line at a time and is better than ReadAllLines for large files.
using closes (and flushes) the file even if an exception is thrown. An unclosed file can stay locked and lose buffered data.
Files fail for reasons outside your control: missing, locked, read-only, disk full. Expect FileNotFoundException, IOException and UnauthorizedAccessException and handle them where you can say something useful.

Practice question 12: persist the inventory

Take your Day 1 inventory. Save it to a text file and reload it on startup.

Solution

string path = Path.Combine(Path.GetTempPath(), "inventory-demo.txt");
File.Delete(path);

// First start: no file yet, so we begin empty
Dictionary<string, int> inventory = InventoryStore.Load(path);
Console.WriteLine($"Loaded {inventory.Count} item(s) at startup");

inventory["Keyboard"] = 12;
inventory["Mouse"] = 4;
InventoryStore.Save(path, inventory);
Console.WriteLine("Saved. File contents:");
Console.WriteLine(File.ReadAllText(path).Replace('\t', '|').TrimEnd());

// Simulate a damaged file, then restart the app
File.AppendAllText(path, "garbage line\nPen\tnotanumber\n");
Dictionary<string, int> reloaded = InventoryStore.Load(path);
Console.WriteLine($"Reloaded {reloaded.Count} item(s): {string.Join(", ", reloaded.Select(p => $"{p.Key}={p.Value}"))}");

public static class InventoryStore
{
    public static Dictionary<string, int> Load(string path)
    {
        var inventory = new Dictionary<string, int>(StringComparer.OrdinalIgnoreCase);
        if (!File.Exists(path)) return inventory;

        using var reader = new StreamReader(path);
        int lineNumber = 0;
        while (reader.ReadLine() is { } line)
        {
            lineNumber++;
            if (string.IsNullOrWhiteSpace(line)) continue;

            string[] parts = line.Split('\t');
            if (parts.Length == 2 && int.TryParse(parts[1], out int quantity) && quantity >= 0)
            {
                inventory[parts[0]] = quantity;
            }
            else
            {
                Console.WriteLine($"Skipping bad line {lineNumber}: {line}");
            }
        }
        return inventory;
    }

    public static void Save(string path, Dictionary<string, int> inventory)
    {
        string tempPath = path + ".tmp";
        using (var writer = new StreamWriter(tempPath))
        {
            foreach (var (name, quantity) in inventory.OrderBy(p => p.Key))
            {
                writer.WriteLine($"{name}\t{quantity}");
            }
        }
        File.Move(tempPath, path, overwrite: true);   // swap in only after the write succeeded
    }
}

Output:

Loaded 0 item(s) at startup
Saved. File contents:
Keyboard|12
Mouse|4
Skipping bad line 3: garbage line
Skipping bad line 4: Pen    notanumber
Reloaded 2 item(s): Keyboard=12, Mouse=4

Why this is the best way to write it:

A missing file means an empty inventory, not a crash. The very first run of any app has no data file yet, and that must be normal.
Every line is validated as it is read. TryParse plus a non-negative check means a hand-edited or damaged line is skipped and reported with its line number, instead of crashing the app or loading garbage.
The save is atomic. It writes to a .tmp file and only then moves it over the real one. If the program dies halfway through writing, the last good file is untouched. The temp file is fully closed before the move because the using block ends first.
A tab separates the fields, because product names are far more likely to contain commas than tabs. A format only works if the separator cannot appear in the data.
Output is sorted by name, so repeated saves produce stable files that are easy to compare.
reader.ReadLine() is { } line is the idiomatic loop: read, test for non-null and bind in one expression.
Persistence is its own class. InventoryStore knows about files; the inventory logic from Day 1 does not. Swapping to JSON or a database later changes one class.

Basics capstone: Library Management console app

Now combine everything from Days 1 and 2 in one program. Build a menu-driven console app for a small library. Requirements:

Books and members as classes, with Book inheriting into PrintedBook and EBook
An interface for lending rules, so the limits and fees can be swapped
An enum for book status
Custom exceptions for domain failures (book not found, already borrowed, loan limit reached)
Dictionary and List storage
File persistence: state survives a restart
Nullable handling for optional data
A menu-driven loop that keeps running after a bad input

Try it yourself before reading on. If you want a plan: start with the model classes, then Library with Borrow/Return, then the menu, and add the file persistence last.

Solution

using System.Globalization;

const string DataFile = "library.dat";

var library = Library.Load(DataFile, new StandardLendingRules());
Console.WriteLine($"Library ready: {library.BookCount} book(s), {library.MemberCount} member(s).");

bool running = true;
while (running)
{
    Console.WriteLine();
    Console.WriteLine("1) Add book  2) Add member  3) Borrow  4) Return  5) Search  6) List books  0) Save and exit");
    string choice = Ask("> ");

    try
    {
        switch (choice)
        {
            case "1": AddBook(); break;
            case "2": AddMember(); break;
            case "3": Borrow(); break;
            case "4": Return(); break;
            case "5": Search(); break;
            case "6": ListBooks(); break;
            case "0":
                library.Save(DataFile);
                Console.WriteLine("Saved. Goodbye!");
                running = false;
                break;
            default:
                Console.WriteLine("Unknown option.");
                break;
        }
    }
    catch (LibraryException ex)
    {
        Console.WriteLine($"Error: {ex.Message}");
    }
}

string Ask(string label)
{
    Console.Write(label.EndsWith("> ") ? label : label + ": ");
    return Console.ReadLine()?.Trim() ?? "0";    // end of input behaves like "exit"
}

void AddBook()
{
    string kind = Ask("Type - (P)rinted or (E)Book").ToUpperInvariant();
    string id = Ask("Id");
    string title = Ask("Title");
    string author = Ask("Author");

    Book book;
    if (kind == "P")
    {
        book = new PrintedBook(id, title, author, Ask("Shelf"));
    }
    else if (kind == "E")
    {
        if (!double.TryParse(Ask("Size in MB"), NumberStyles.Float, CultureInfo.InvariantCulture, out double mb))
        {
            throw new LibraryException("Size must be a number.");
        }
        book = new EBook(id, title, author, mb);
    }
    else
    {
        throw new LibraryException("Type must be P or E.");
    }

    library.AddBook(book);
    Console.WriteLine($"Added {book.Describe()}");
}

void AddMember()
{
    string id = Ask("Member id");
    string name = Ask("Name");
    string email = Ask("Email (optional)");
    library.AddMember(new Member(id, name, string.IsNullOrWhiteSpace(email) ? null : email));
    Console.WriteLine("Member added.");
}

void Borrow()
{
    Loan loan = library.Borrow(Ask("Member id"), Ask("Book id"), Today());
    Console.WriteLine($"Borrowed. Due back on {loan.DueDate:yyyy-MM-dd}.");
}

void Return()
{
    decimal fee = library.Return(Ask("Book id"), Today());
    Console.WriteLine($"Returned. Late fee: ${fee:F2}");
}

void Search()
{
    var results = library.Search(Ask("Search text")).ToList();
    Console.WriteLine(results.Count == 0 ? "No matches." : string.Join(Environment.NewLine, results.Select(b => b.Describe())));
}

void ListBooks()
{
    foreach (Book book in library.AllBooks) Console.WriteLine(book.Describe());
}

static DateOnly Today() => DateOnly.FromDateTime(DateTime.Today);

// ---------------------------------------------------------------- domain

public enum BookStatus { Available, Borrowed }

public abstract class Book
{
    protected Book(string id, string title, string author)
    {
        Id = Clean(id, nameof(id));
        Title = Clean(title, nameof(title));
        Author = Clean(author, nameof(author));
    }

    public string Id { get; }
    public string Title { get; }
    public string Author { get; }
    public BookStatus Status { get; internal set; } = BookStatus.Available;

    public abstract string Kind { get; }
    public abstract int LoanDays { get; }
    public abstract string ExtraData { get; }          // the one field that differs per subtype

    public virtual string Describe() => $"[{Id}] {Title} by {Author} ({Kind}, {Status})";

    protected static string Clean(string value, string field)
    {
        if (string.IsNullOrWhiteSpace(value) || value.Contains('|'))
        {
            throw new LibraryException($"{field} is required and cannot contain '|'.");
        }
        return value.Trim();
    }
}

public sealed class PrintedBook : Book
{
    public PrintedBook(string id, string title, string author, string shelf) : base(id, title, author)
        => Shelf = Clean(shelf, nameof(shelf));

    public string Shelf { get; }
    public override string Kind => "Printed";
    public override int LoanDays => 21;
    public override string ExtraData => Shelf;
    public override string Describe() => $"{base.Describe()} shelf {Shelf}";
}

public sealed class EBook : Book
{
    public EBook(string id, string title, string author, double sizeMb) : base(id, title, author)
    {
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(sizeMb);
        SizeMb = sizeMb;
    }

    public double SizeMb { get; }
    public override string Kind => "EBook";
    public override int LoanDays => 14;
    public override string ExtraData => SizeMb.ToString(CultureInfo.InvariantCulture);
    public override string Describe() => $"{base.Describe()} {SizeMb:F1} MB";
}

public class Member
{
    public Member(string id, string name, string? email = null)
    {
        if (string.IsNullOrWhiteSpace(id) || string.IsNullOrWhiteSpace(name) || id.Contains('|') || name.Contains('|'))
        {
            throw new LibraryException("Member id and name are required and cannot contain '|'.");
        }
        Id = id.Trim();
        Name = name.Trim();
        Email = email?.Trim();
    }

    public string Id { get; }
    public string Name { get; }
    public string? Email { get; }                      // optional, so it is nullable
}

public record Loan(string BookId, string MemberId, DateOnly DueDate);

// ---------------------------------------------------------------- rules

public interface ILendingRules
{
    int MaxActiveLoans { get; }
    DateOnly GetDueDate(Book book, DateOnly borrowedOn);
    decimal CalculateLateFee(Loan loan, DateOnly returnedOn);
}

public class StandardLendingRules : ILendingRules
{
    public int MaxActiveLoans => 3;

    public DateOnly GetDueDate(Book book, DateOnly borrowedOn) => borrowedOn.AddDays(book.LoanDays);

    public decimal CalculateLateFee(Loan loan, DateOnly returnedOn)
    {
        int daysLate = returnedOn.DayNumber - loan.DueDate.DayNumber;
        return daysLate > 0 ? daysLate * 0.25m : 0m;
    }
}

// ---------------------------------------------------------------- exceptions

public class LibraryException : Exception
{
    public LibraryException(string message) : base(message) { }
}

public class NotFoundException : LibraryException
{
    public NotFoundException(string what, string id) : base($"{what} '{id}' was not found.") { }
}

public class BookUnavailableException : LibraryException
{
    public BookUnavailableException(string title) : base($"'{title}' is already borrowed.") { }
}

public class LendingLimitException : LibraryException
{
    public LendingLimitException(string member, int limit) : base($"{member} already has {limit} active loans.") { }
}

// ---------------------------------------------------------------- the library

public class Library
{
    private readonly Dictionary<string, Book> _books = new(StringComparer.OrdinalIgnoreCase);
    private readonly Dictionary<string, Member> _members = new(StringComparer.OrdinalIgnoreCase);
    private readonly List<Loan> _loans = new();
    private readonly ILendingRules _rules;

    public Library(ILendingRules rules) => _rules = rules;

    public int BookCount => _books.Count;
    public int MemberCount => _members.Count;
    public IEnumerable<Book> AllBooks => _books.Values.OrderBy(b => b.Title);

    public void AddBook(Book book)
    {
        if (!_books.TryAdd(book.Id, book)) throw new LibraryException($"A book with id '{book.Id}' already exists.");
    }

    public void AddMember(Member member)
    {
        if (!_members.TryAdd(member.Id, member)) throw new LibraryException($"A member with id '{member.Id}' already exists.");
    }

    public Loan Borrow(string memberId, string bookId, DateOnly today)
    {
        Member member = FindMember(memberId);
        Book book = FindBook(bookId);

        if (book.Status != BookStatus.Available) throw new BookUnavailableException(book.Title);
        if (_loans.Count(l => l.MemberId == member.Id) >= _rules.MaxActiveLoans)
        {
            throw new LendingLimitException(member.Name, _rules.MaxActiveLoans);
        }

        var loan = new Loan(book.Id, member.Id, _rules.GetDueDate(book, today));
        _loans.Add(loan);
        book.Status = BookStatus.Borrowed;
        return loan;
    }

    public decimal Return(string bookId, DateOnly today)
    {
        Book book = FindBook(bookId);
        Loan? loan = _loans.Find(l => l.BookId == book.Id);
        if (loan is null) throw new LibraryException($"'{book.Title}' is not on loan.");

        _loans.Remove(loan);
        book.Status = BookStatus.Available;
        return _rules.CalculateLateFee(loan, today);
    }

    public IEnumerable<Book> Search(string text) => _books.Values.Where(b =>
        b.Title.Contains(text, StringComparison.OrdinalIgnoreCase) ||
        b.Author.Contains(text, StringComparison.OrdinalIgnoreCase));

    private Book FindBook(string id) =>
        _books.TryGetValue(id.Trim(), out Book? book) ? book : throw new NotFoundException("Book", id);

    private Member FindMember(string id) =>
        _members.TryGetValue(id.Trim(), out Member? member) ? member : throw new NotFoundException("Member", id);

    // ------------------------------------------------------------ persistence

    public void Save(string path)
    {
        string tempPath = path + ".tmp";
        using (var writer = new StreamWriter(tempPath))
        {
            foreach (Book b in _books.Values)
                writer.WriteLine($"B|{b.Kind}|{b.Id}|{b.Title}|{b.Author}|{b.Status}|{b.ExtraData}");
            foreach (Member m in _members.Values)
                writer.WriteLine($"M|{m.Id}|{m.Name}|{m.Email}");
            foreach (Loan l in _loans)
                writer.WriteLine($"L|{l.BookId}|{l.MemberId}|{l.DueDate:yyyy-MM-dd}");
        }
        File.Move(tempPath, path, overwrite: true);
    }

    public static Library Load(string path, ILendingRules rules)
    {
        var library = new Library(rules);
        if (!File.Exists(path)) return library;

        foreach (string line in File.ReadLines(path))
        {
            string[] f = line.Split('|');
            try
            {
                switch (f[0])
                {
                    case "B":
                        Book book = f[1] == "Printed"
                            ? new PrintedBook(f[2], f[3], f[4], f[6])
                            : new EBook(f[2], f[3], f[4], double.Parse(f[6], CultureInfo.InvariantCulture));
                        book.Status = Enum.Parse<BookStatus>(f[5]);
                        library.AddBook(book);
                        break;
                    case "M":
                        library.AddMember(new Member(f[1], f[2], string.IsNullOrEmpty(f[3]) ? null : f[3]));
                        break;
                    case "L":
                        library._loans.Add(new Loan(f[1], f[2], DateOnly.ParseExact(f[3], "yyyy-MM-dd", CultureInfo.InvariantCulture)));
                        break;
                }
            }
            catch (Exception ex) when (ex is FormatException or IndexOutOfRangeException or ArgumentException or LibraryException)
            {
                Console.WriteLine($"Skipped unreadable line: {line}");
            }
        }
        return library;
    }
}

Sample session. The menu line is shown once and the later repeats are omitted for space. Typed input follows each prompt:

Library ready: 0 book(s), 0 member(s).

1) Add book  2) Add member  3) Borrow  4) Return  5) Search  6) List books  0) Save and exit
> 2
Member id: m1
Name: Asha
Email (optional):
Member added.
> 1
Type - (P)rinted or (E)Book: P
Id: b1
Title: Clean Code
Author: Robert Martin
Shelf: A3
Added [b1] Clean Code by Robert Martin (Printed, Available) shelf A3
> 1
Type - (P)rinted or (E)Book: E
Id: b2
Title: The Pragmatic Programmer
Author: Hunt and Thomas
Size in MB: 2.5
Added [b2] The Pragmatic Programmer by Hunt and Thomas (EBook, Available) 2.5 MB
> 3
Member id: m1
Book id: b1
Borrowed. Due back on 2026-11-17.
> 3
Member id: m1
Book id: b1
Error: 'Clean Code' is already borrowed.
> 3
Member id: m9
Book id: b2
Error: Member 'm9' was not found.
> 5
Search text: pragmatic
[b2] The Pragmatic Programmer by Hunt and Thomas (EBook, Available) 2.5 MB
> 0
Saved. Goodbye!

Restarting the app proves the persistence works. The second run loads everything back, including the loan:

Library ready: 2 book(s), 1 member(s).

1) Add book  2) Add member  3) Borrow  4) Return  5) Search  6) List books  0) Save and exit
> 6
[b1] Clean Code by Robert Martin (Printed, Borrowed) shelf A3
[b2] The Pragmatic Programmer by Hunt and Thomas (EBook, Available) 2.5 MB
> 4
Book id: b1
Returned. Late fee: $0.00
> 4
Book id: b1
Error: 'Clean Code' is not on loan.
> 0
Saved. Goodbye!

The due date depends on the day you run it: 21 days for a printed book, 14 for an ebook.

Why this is the best way to write it:

Each part has one job. Models hold data (Book, Member, Loan), ILendingRules holds policy, the exception classes hold failure meanings, Library holds the business logic, and the top of Program.cs only does menus and console input and output. There is not a single business rule in the menu code.
Inheritance is used only where behaviour really differs. PrintedBook and EBook differ in loan length, description and the one extra field. Book is abstract, so nobody can create a generic book that has no loan length.
Lending rules sit behind an interface and are handed to Library through its constructor. Changing the loan limit or the late fee means a new ILendingRules class and no change to Library. This is a first taste of dependency injection, which you will meet on Day 4.
today is passed into Borrow and Return instead of calling DateTime.Today inside. To test a 10-days-late return, pass a date 10 days ahead. Code that secretly reads the clock cannot be tested that way.
Expected failures are exceptions with domain names. The menu loop has a single catch (LibraryException), so every anticipated problem is reported in one place, while a real bug (such as a NullReferenceException) still crashes visibly.
Dictionaries for lookups, a list for loans. Books and members are found by id, so they are Dictionary instances with a case-insensitive comparer. Loans are a short ordered list. TryAdd rejects duplicate ids in one step.
The text format cannot be corrupted by user input. Fields are separated by |, and every constructor rejects values containing |. Each line starts with a record type letter (B, M, L) so one file holds all three kinds.
Saving is atomic and loading is tolerant. The file is written to a temp file and swapped in. Loading skips unreadable lines with an exception filter (when (ex is FormatException or ...)) instead of refusing to start.
Nullable handling is honest. Email is string? because it is genuinely optional, empty input becomes null, Find returns Loan? and the code checks for null immediately.
End of input counts as "exit". If the console input ends, the loop stops cleanly instead of spinning forever on null.

Where each concept appears

Day 1: const, TryParse, switch, while, Dictionary, List, methods with out and default values, string formatting
Classes and properties: Book, Member, Library, with private state and validating constructors
static/readonly: readonly collections and rules; static helpers Today and Load
Inheritance, abstract, virtual/override, interface: Book family and ILendingRules
Enums and records: BookStatus and Loan
Exceptions: the LibraryException family and the single catch in the menu
Null handling: Email, Loan?, ?., ?? and conditional expressions
File I/O: Save and Load with StreamWriter, atomic move, tolerant parsing

Stretch goals (optional): add a reservation queue, a premium member type with a higher loan limit through a second ILendingRules class, and an overdue report. The report is a perfect warm-up for LINQ on Day 3.

Five classic Day 2 mistakes

Each one follows the same pattern: what people write, why it hurts, what to write instead.

Public fields and public setters on everything. public decimal Balance; lets any code set any value, so no rule you wrote can be trusted. Make the setter private and expose operations (Deposit, Withdraw).
An empty catch. catch (Exception) { } hides every failure, including real bugs, and the program carries on with bad state. Catch specific exceptions you can handle, and log or rethrow the rest.
throw ex; instead of throw;. It erases the stack trace, so the log points at the catch block rather than the real failure. Use throw; to rethrow.
Silencing nullable warnings with !. user!.Address!.City compiles cleanly and crashes the same way as before. Use ?. and ?? and make the decision explicit.
Building paths with + and forgetting to close files. folder + "/" + name breaks on other operating systems, and an unclosed StreamWriter can lose the last lines it buffered. Use Path.Combine and using.

Key lessons

A class guards its own data: private state, validating constructors, public methods
private set and get-only properties are the everyday tools of encapsulation
const is compile-time, readonly is assign-once, static is shared by everything; be suspicious of mutable statics
Immutable objects never change: operations return new objects
Program against the base type or interface, and let polymorphism pick the behaviour
Inherit for "is-a", implement an interface for "can-do"
Record for data, class for behaviour and identity, struct for tiny values
Catch specific exceptions, put custom data on custom exceptions, rethrow with throw;
?., ?? and ??= turn crashes into decisions; avoid !
Close files with using, build paths with Path.Combine, and save atomically

Summary

Day 1 gave you the vocabulary. Day 2 gives you the grammar of real programs: objects that protect themselves, hierarchies that let new behaviour plug in without touching old code, value types that behave as values, errors that carry meaning, nulls that are handled on purpose, and data that survives a restart. The Library app uses every one of them together, which is exactly how real applications work. If you can rebuild it from a blank file, you are ready for Day 3: generics, collections, delegates, events, LINQ and iterators.

C# Basics Day 1: Types, Strings, Control Flow, Methods and Collections Explained With Five Practice Projects

Manohari Jayachandran — Sun, 25 Oct 2026 20:25:19 +0000

Why this post exists

Most people learn C# by reading about it. The ones who get good learn it by writing small programs that fight back. This post is Day 1 of a six-day plan to learn C# deeply: Days 1 and 2 cover the basics, Days 3 and 4 the mid-level concepts, Days 5 and 6 the advanced ones, and then you build one large project that uses all of it.

Day 1 covers the language core: types and conversion, strings, control flow, methods, and collections. For each concept you get the same five steps: what it is, an analogy, a short example, a practice question, and a complete solution with the reasons it is written that way. Try the practice question yourself before you read the solution. That is where the learning happens.

All code targets .NET 8 or later and uses top-level statements, so you can paste each solution into the Program.cs of a new console project (dotnet new console) and run it.

Concept 1: Types, variables, constants, operators and type conversion

What it is. C# is statically typed: every variable has a type that is fixed when you write the code, and the compiler refuses to mix types carelessly. A variable stores a value, a const is a value that can never change, operators (+ - * / % == && ||) combine values, and conversion is how you move a value from one type to another.

The analogy: jars in a kitchen. Each jar has a label and only holds one kind of thing: a flour jar, a sugar jar. Pouring a small jar into a bigger one always works (implicit conversion). Pouring a big jar into a small one may spill, so you must say so out loud (an explicit cast like (int)9.99, which drops the .99). Pouring something unknown into a jar is risky, so you check it first: that is what int.TryParse does. A const is a jar with the label engraved in stone.

int age = 30;                   // whole number
double price = 19.99;           // fractional number (binary floating point)
decimal balance = 1050.75m;     // money: exact base-10 arithmetic (note the m)
bool isActive = true;
char grade = 'A';
string name = "Asha";
var count = 10;                 // 'var' lets the compiler infer int; it is still strongly typed

const double Pi = 3.14159;      // fixed at compile time, can never change

int a = 7, b = 2;
Console.WriteLine(a / b);           // 3   (int / int is integer division)
Console.WriteLine(a % b);           // 1   (remainder)
Console.WriteLine((double)a / b);   // 3.5 (cast one side first)

Console.WriteLine(0.1 + 0.2 == 0.3);      // False (double cannot store 0.1 exactly)
Console.WriteLine(0.1m + 0.2m == 0.3m);   // True  (decimal can)

int small = 42;
long big = small;               // implicit conversion: widening, always safe
double d = 9.99;
int truncated = (int)d;         // explicit cast: you accept the loss, result is 9
Console.WriteLine($"{big} {truncated}");

string[] inputs = { "123", "12x", "" };
foreach (string text in inputs)
{
    if (int.TryParse(text, out int parsed))
        Console.WriteLine($"'{text}' -> {parsed}");
    else
        Console.WriteLine($"'{text}' is not a valid int");
}

What is happening here:

int, double, decimal, bool, char and string are the everyday types. Use decimal for money, because double stores binary fractions and cannot represent 0.1 exactly (the 0.1 + 0.2 == 0.3 line prints False).
7 / 2 is 3, not 3.5, because both sides are int. Cast one side to double first.
(int)d is an explicit cast: it truncates, it does not round.
TryParse returns true or false and hands the result back through an out variable. It never throws on bad input, which is why it is the right tool for anything a user types.

Practice question 1: temperature converter

Build a console app that converts between Celsius, Fahrenheit and Kelvin. It must read the values from console input and reject invalid input without crashing: unknown scale letters, text instead of numbers, and temperatures below absolute zero.

Solution

using System.Globalization;

const double AbsoluteZeroKelvin = 0.0;

Console.WriteLine("Temperature converter. Type q at any prompt to quit.");

while (true)
{
    Console.Write("Convert from (C/F/K): ");
    string? fromInput = Console.ReadLine();
    if (IsQuit(fromInput)) break;
    if (!TryParseScale(fromInput, out Scale from))
    {
        Console.WriteLine("Please enter C, F or K.");
        continue;
    }

    Console.Write("Value: ");
    string? valueInput = Console.ReadLine();
    if (IsQuit(valueInput)) break;
    if (!double.TryParse(valueInput, NumberStyles.Float, CultureInfo.InvariantCulture, out double value))
    {
        Console.WriteLine("That is not a number.");
        continue;
    }

    double kelvin = ToKelvin(value, from);
    if (Math.Round(kelvin, 6) < AbsoluteZeroKelvin)
    {
        Console.WriteLine("That is below absolute zero, which is physically impossible.");
        continue;
    }

    Console.Write("Convert to (C/F/K): ");
    string? toInput = Console.ReadLine();
    if (IsQuit(toInput)) break;
    if (!TryParseScale(toInput, out Scale to))
    {
        Console.WriteLine("Please enter C, F or K.");
        continue;
    }

    double result = FromKelvin(kelvin, to);
    Console.WriteLine($"{value:F2} {from} = {result:F2} {to}");
}

static bool IsQuit(string? input) =>
    string.Equals(input?.Trim(), "q", StringComparison.OrdinalIgnoreCase);

static bool TryParseScale(string? input, out Scale scale)
{
    switch (input?.Trim().ToUpperInvariant())
    {
        case "C": scale = Scale.Celsius; return true;
        case "F": scale = Scale.Fahrenheit; return true;
        case "K": scale = Scale.Kelvin; return true;
        default: scale = default; return false;
    }
}

static double ToKelvin(double value, Scale scale) => scale switch
{
    Scale.Celsius => value + 273.15,
    Scale.Fahrenheit => (value - 32) * 5 / 9 + 273.15,
    Scale.Kelvin => value,
    _ => throw new ArgumentOutOfRangeException(nameof(scale))
};

static double FromKelvin(double kelvin, Scale scale) => scale switch
{
    Scale.Celsius => kelvin - 273.15,
    Scale.Fahrenheit => (kelvin - 273.15) * 9 / 5 + 32,
    Scale.Kelvin => kelvin,
    _ => throw new ArgumentOutOfRangeException(nameof(scale))
};

enum Scale { Celsius, Fahrenheit, Kelvin }

Sample run:

Temperature converter. Type q at any prompt to quit.
Convert from (C/F/K): C
Value: 100
Convert to (C/F/K): F
100.00 Celsius = 212.00 Fahrenheit
Convert from (C/F/K): F
Value: -500
That is below absolute zero, which is physically impossible.
Convert from (C/F/K): K
Value: x
That is not a number.
Convert from (C/F/K): q

Why this is the best way to write it:

Kelvin is the hub. Converting every scale to Kelvin and then from Kelvin means two small formulas per scale instead of six scale-to-scale formulas. Adding Rankine later costs two lines, not a rewrite.
One validation rule covers every scale. Checking kelvin < 0 after converting means you never write separate minimum values (-273.15, -459.67, 0) for each scale.
Math.Round(kelvin, 6) guards against floating-point noise. Converting -459.67 F can land at -0.00000000000003 K, which would wrongly be rejected. Rounding to six places removes that.
TryParse with CultureInfo.InvariantCulture means 36.6 works on every machine, even ones whose regional settings use a comma as the decimal separator. Bad input takes the continue path instead of an exception.
An enum for the scale means the compiler catches a typo like Scale.Kelvn, which a string comparison never would. The switch expressions throw in the _ arm so a future new enum member cannot be silently ignored.
TryParseScale is its own method with an out parameter, the same shape as int.TryParse, so the main loop reads like a list of checks.

Concept 2: Strings, interpolation and StringBuilder

What it is. A string is a sequence of characters. Strings in C# are immutable: no method ever changes a string, every operation such as ToUpper or Replace returns a new one. String interpolation ($"Hello {name}") puts values straight into text. StringBuilder is the tool for building a string piece by piece.

The analogy: a string is a sentence carved in stone. You cannot change a letter; you carve a whole new tablet. Doing that once is fine. Doing it 10,000 times in a loop leaves a pile of discarded tablets for the garbage collector to clear. A StringBuilder is a whiteboard: you write, rub out, and add as much as you like, and you only carve a tablet (ToString()) when you are finished.

using System.Text;

string s = "hello";
string t = s.ToUpper();                 // creates a NEW string; s is untouched
Console.WriteLine($"{s} -> {t}");       // hello -> HELLO

string name = "Asha";
int items = 3;
decimal total = 59.5m;
Console.WriteLine($"{name} bought {items} items for {total:F2}");   // Asha bought 3 items for 59.50

string padded = "  C# is fun  ";
Console.WriteLine(padded.Trim());                          // C# is fun
Console.WriteLine(padded.Contains("fun"));                 // True
string[] parts = "a,b,c".Split(',');
Console.WriteLine(string.Join(" | ", parts));              // a | b | c
Console.WriteLine(string.Equals("Hi", "hI", StringComparison.OrdinalIgnoreCase));   // True

// Building a string in a loop: use StringBuilder
var sb = new StringBuilder();
for (int i = 1; i <= 5; i++)
{
    sb.Append(i).Append(',');
}
sb.Length--;                            // drop the trailing comma
Console.WriteLine(sb.ToString());       // 1,2,3,4,5

What is happening here:

s.ToUpper() returns a new string and leaves s alone. Forgetting to use the return value is a very common beginner bug.
{total:F2} formats to two decimal places. The text after the colon is a format string.
string.Equals(..., StringComparison.OrdinalIgnoreCase) is the correct way to compare ignoring case. Avoid a.ToLower() == b.ToLower(), which allocates two throwaway strings.
Use StringBuilder when you append in a loop. For a handful of concatenations, plain + or interpolation is simpler and just as fast.

Practice question 2: word-frequency counter and palindrome checker

Write two functions. The first counts how often each word appears in a piece of text, ignoring case and punctuation. The second returns true if a phrase is a palindrome, again ignoring case, spaces and punctuation ("A man, a plan, a canal: Panama!" is one).

Solution

using System.Text;

string sample = "A man, a plan, a canal: Panama! The man said: don't panic. The plan, the plan!";

Console.WriteLine("Word frequency:");
foreach (var (word, count) in CountWords(sample).OrderByDescending(p => p.Value).ThenBy(p => p.Key))
{
    Console.WriteLine($"  {word,-8} {count}");
}

foreach (string text in new[] { "A man, a plan, a canal: Panama!", "Hello, World", "Was it a car or a cat I saw?" })
{
    Console.WriteLine($"\"{text}\" is a palindrome: {IsPalindrome(text)}");
}

static Dictionary<string, int> CountWords(string text)
{
    var counts = new Dictionary<string, int>();
    var word = new StringBuilder();

    foreach (char c in text)
    {
        if (char.IsLetterOrDigit(c) || c == '\'')
        {
            word.Append(char.ToLowerInvariant(c));
        }
        else
        {
            AddWord(counts, word);
        }
    }
    AddWord(counts, word); // the last word has no trailing separator

    return counts;
}

static void AddWord(Dictionary<string, int> counts, StringBuilder word)
{
    if (word.Length == 0) return;

    string w = word.ToString();
    counts[w] = counts.GetValueOrDefault(w) + 1;
    word.Clear();
}

static bool IsPalindrome(string text)
{
    var cleaned = new StringBuilder(text.Length);
    foreach (char c in text)
    {
        if (char.IsLetterOrDigit(c))
        {
            cleaned.Append(char.ToLowerInvariant(c));
        }
    }

    int left = 0, right = cleaned.Length - 1;
    while (left < right)
    {
        if (cleaned[left++] != cleaned[right--]) return false;
    }
    return true;
}

Output:

Word frequency:
  a        3
  plan     3
  the      3
  man      2
  canal    1
  don't    1
  panama   1
  panic    1
  said     1
"A man, a plan, a canal: Panama!" is a palindrome: True
"Hello, World" is a palindrome: False
"Was it a car or a cat I saw?" is a palindrome: True

Why this is the best way to write it:

One pass over the text, no punctuation list. Asking char.IsLetterOrDigit(c) is better than listing punctuation to remove, because it also handles characters you did not think of, including accented letters.
One StringBuilder is reused for every word. Clear() empties it without allocating a new one, so there is no string concatenation inside the loop.
counts[w] = counts.GetValueOrDefault(w) + 1 is the standard counting idiom: a word not seen before counts as 0, then becomes 1. No ContainsKey check, no KeyNotFoundException.
The final AddWord call after the loop catches the last word, which has no separator after it. Forgetting this is the classic off-by-one bug in word counters.
The palindrome check uses two pointers moving inwards and stops at the first mismatch. The shortcut of reversing the cleaned string and comparing works too, but it allocates a second string.
A design choice worth knowing: the apostrophe is kept inside words so "don't" stays one word. The price is that a word wrapped in single quotes keeps its quotes. Decide that rule on purpose and write it down.

Concept 3: Control flow: if, switch, for, foreach and while

What it is. Control flow decides which code runs and how many times. if/else chooses between paths. switch chooses between many paths based on one value, and the modern switch expression returns a value. for, foreach and while repeat code.

The analogy: driving. if is a fork in the road. switch is the signboard at a big junction listing every exit. A for loop is laps round a track with a lap counter. foreach is walking down a street visiting every house. while is waiting at a red light: you stay until the condition changes. break is leaving the roundabout early and continue is skipping this house and moving to the next.

int score = 72;

// if / else if / else
if (score >= 90) Console.WriteLine("A");
else if (score >= 70) Console.WriteLine("B");
else Console.WriteLine("C");

// switch statement
DayOfWeek day = DayOfWeek.Saturday;
switch (day)
{
    case DayOfWeek.Saturday:
    case DayOfWeek.Sunday:
        Console.WriteLine("Weekend");
        break;
    default:
        Console.WriteLine("Weekday");
        break;
}

// switch expression: produces a value
string label = score switch
{
    >= 90 => "Excellent",
    >= 70 => "Good",
    _ => "Keep going"
};
Console.WriteLine(label);

// for: you need the index
for (int i = 0; i < 3; i++) Console.Write($"{i} ");
Console.WriteLine();

// foreach: you just need each item
foreach (string fruit in new[] { "apple", "banana" }) Console.Write($"{fruit} ");
Console.WriteLine();

// while: repeat until a condition changes
int n = 1;
while (n < 100) n *= 3;
Console.WriteLine(n);

// break and continue
for (int i = 1; i <= 10; i++)
{
    if (i % 2 == 0) continue;   // skip evens
    if (i > 7) break;           // stop entirely
    Console.Write($"{i} ");
}
Console.WriteLine();

What is happening here:

Use for when you need the index, foreach when you just need each item, and while when you do not know in advance how many times to repeat.
A switch expression (score switch { >= 90 => ... }) produces a value, so it can be assigned or returned directly. The arms are checked top to bottom, so order matters. _ is the catch-all.
In a classic switch statement, every case must end in break (or return). Stacked cases such as Saturday: followed by Sunday: share one body.
foreach cannot change the collection it is walking. Adding or removing items inside it throws an InvalidOperationException.

Practice question 3: number-guessing game

Build a number-guessing game with a limited number of attempts and hints. The hint text must come from a switch expression. Invalid input must not crash the game.

Solution

const int Min = 1;
const int Max = 100;
const int MaxAttempts = 7;

int secret = Random.Shared.Next(Min, Max + 1);
int attemptsLeft = MaxAttempts;

Console.WriteLine($"I'm thinking of a number between {Min} and {Max}. You have {MaxAttempts} attempts.");

while (attemptsLeft > 0)
{
    Console.Write($"Guess ({attemptsLeft} left): ");

    if (!int.TryParse(Console.ReadLine(), out int guess) || guess < Min || guess > Max)
    {
        Console.WriteLine($"Enter a whole number from {Min} to {Max}. That did not cost an attempt.");
        continue;
    }

    attemptsLeft--;

    if (guess == secret)
    {
        Console.WriteLine($"Correct! You used {MaxAttempts - attemptsLeft} attempt(s).");
        return;
    }

    Console.WriteLine(GetHint(guess, secret));
}

Console.WriteLine($"Out of attempts. The number was {secret}.");

static string GetHint(int guess, int secret)
{
    string direction = guess < secret ? "higher" : "lower";

    return Math.Abs(guess - secret) switch
    {
        <= 5 => $"Burning hot! Go {direction}.",
        <= 15 => $"Warm. Go {direction}.",
        <= 30 => $"Cool. Go {direction}.",
        _ => $"Cold. Go {direction}."
    };
}

Sample run (secret number 42):

I'm thinking of a number between 1 and 100. You have 7 attempts.
Guess (7 left): abc
Enter a whole number from 1 to 100. That did not cost an attempt.
Guess (7 left): 50
Warm. Go lower.
Guess (6 left): 30
Warm. Go higher.
Guess (5 left): 40
Burning hot! Go higher.
Guess (4 left): 42
Correct! You used 4 attempt(s).

Why this is the best way to write it:

Settings are const values at the top. Changing the range or the attempt limit is a one-line edit, and the text messages update themselves.
A while loop with an attemptsLeft counter is clearer than a for loop here, because invalid input must not use up an attempt. Changing a for loop's counter inside the body is a trap.
int.TryParse plus a range check in one condition, so a letter, an empty line and 0 or 101 all take the same friendly path.
GetHint is a separate pure method. It takes numbers in and returns text out, with no Console calls, so you can test it without playing the game. Input/output stays in the loop, logic stays in the method.
A switch expression with relational patterns (<= 5, <= 15) replaces an if/else ladder with four readable lines. The order matters: the smallest limit comes first.
Random.Shared is thread-safe and needs no new Random(), which can produce repeated numbers if created in quick succession on older runtimes.

Concept 4: Methods: parameters, out, ref, optional and named arguments, params, expression-bodied members

What it is. A method is a named block of code that takes inputs (parameters) and may return a result. Writing methods is how you stop repeating yourself and how you give a piece of logic a name.

The analogy: a vending machine. You put in a coin and a selection (parameters), and it gives you back a snack (the return value). ref is handing over your original document so the clerk can edit it, rather than a photocopy. out is a machine with a second delivery slot: it hands back extra items besides the main one. params is a bag that takes any number of items. Optional parameters are the options that have a default, like "sugar: none" unless you say otherwise.

Console.WriteLine(Greet("Asha"));                              // Hello, Asha!
Console.WriteLine(Greet("Asha", greeting: "Welcome"));         // Welcome, Asha!   (named + optional)

Console.WriteLine(Sum(1, 2, 3, 4));                            // 10  (params)

int x = 1, y = 2;
Swap(ref x, ref y);                                            // ref: modifies the caller's variables
Console.WriteLine($"{x} {y}");                                 // 2 1

Console.WriteLine(Square(9));                                  // 81

static string Greet(string name, string greeting = "Hello") => $"{greeting}, {name}!";

static int Sum(params int[] numbers)
{
    int total = 0;
    foreach (int n in numbers) total += n;
    return total;
}

static void Swap(ref int a, ref int b) => (a, b) = (b, a);

static int Square(int n) => n * n;      // expression-bodied member

What is happening here:

By default arguments are passed by value: the method works on a copy. ref passes the variable itself, so the method can change the caller's variable.
out means the method must assign that parameter before it returns. It is how int.TryParse returns both a success flag and a value.
Optional parameters need a default value and must come last. Named arguments (greeting: "Welcome") make a call readable and let you skip optional ones.
params int[] lets the caller write Sum(1, 2, 3, 4) instead of building an array.
=> after the signature is an expression-bodied member: for one-line methods it removes the braces and the return.

Practice question 4: GetStats with out parameters, then with a tuple

Write GetStats(int[] nums) that returns the minimum, maximum and average using out parameters. Then rewrite it so it returns a tuple instead. Decide what should happen for an empty array.

Solution

int[] data = { 4, 9, -2, 15, 7 };

// Version 1: out parameters
if (TryGetStats(data, out int min, out int max, out double average))
{
    Console.WriteLine($"out version:   min={min}, max={max}, average={average:F2}");
}

// Version 2: tuple return, deconstructed at the call site
var (tMin, tMax, tAverage) = GetStats(data);
Console.WriteLine($"tuple version: min={tMin}, max={tMax}, average={tAverage:F2}");

// Named element access also works
var stats = GetStats(data);
Console.WriteLine($"range = {stats.Max - stats.Min}");

static bool TryGetStats(int[] nums, out int min, out int max, out double average)
{
    if (nums is null || nums.Length == 0)
    {
        min = max = 0;
        average = 0;
        return false;
    }

    min = max = nums[0];
    long sum = 0; // long so a big array of big ints cannot overflow
    foreach (int n in nums)
    {
        if (n < min) min = n;
        if (n > max) max = n;
        sum += n;
    }
    average = (double)sum / nums.Length;
    return true;
}

static (int Min, int Max, double Average) GetStats(int[] nums)
{
    ArgumentNullException.ThrowIfNull(nums);
    if (nums.Length == 0)
    {
        throw new ArgumentException("Array must contain at least one element.", nameof(nums));
    }

    int min = nums[0], max = nums[0];
    long sum = 0;
    foreach (int n in nums)
    {
        if (n < min) min = n;
        if (n > max) max = n;
        sum += n;
    }
    return (min, max, (double)sum / nums.Length);
}

Output:

out version:   min=-2, max=15, average=6.60
tuple version: min=-2, max=15, average=6.60
range = 17

Why this is the best way to write it:

The out version follows the Try pattern (TryGetStats returns a bool), the same shape as int.TryParse. The caller is forced to deal with the empty-array case, because the if is how they get the values.
The out version still assigns every out parameter on the failure path. The compiler requires it, and it keeps the values predictable.
The tuple version reads better at the call site: var (min, max, avg) = GetStats(data); or stats.Max - stats.Min. Named tuple elements (Min, Max, Average) document what each value is. Prefer tuples for new code; you will still meet out in existing APIs.
An empty array is handled deliberately. In the tuple version, passing an empty array is a programming error, so it throws ArgumentException. In the Try version it is a normal outcome, so it returns false. Pick one rule per method and stay consistent.
ArgumentNullException.ThrowIfNull is a guard clause: reject bad input in the first line so the rest of the method can assume good data.
The sum is a long, so a large array of large int values cannot overflow before the division. The result is cast with (double)sum / nums.Length to avoid integer division.
One loop computes all three values. The shortcut (nums.Min(), nums.Max(), nums.Average()) is a good one-liner for small data, but it walks the array three times.

Concept 5: Arrays, List and Dictionary

What it is. Collections hold many values together. An array has a fixed size. A List<T> grows and shrinks. A Dictionary<TKey, TValue> stores key and value pairs and finds a value by its key almost instantly.

The analogy: an array is an egg carton: a fixed number of numbered slots, and you cannot add a thirteenth egg to a dozen carton. A List<T> is a shopping list on a notepad: add and cross out items as you like. A Dictionary is a coat check: you hand over a ticket (the key) and get exactly your coat (the value) back immediately, without anyone searching the whole rack.

// Array: fixed size, fastest, indexed from 0
int[] scores = new int[3] { 90, 75, 82 };
scores[1] = 80;
Console.WriteLine(scores.Length);          // 3 (cannot grow)

// List<T>: grows and shrinks
var names = new List<string> { "Asha", "Ravi" };
names.Add("Meena");
names.Remove("Ravi");
Console.WriteLine($"{names.Count}: {string.Join(", ", names)}");   // 2: Asha, Meena

// Dictionary<K,V>: look up a value by its key
var stock = new Dictionary<string, int>
{
    ["pen"] = 10,
    ["book"] = 4
};
stock["pen"] += 5;                         // update
stock["lamp"] = 2;                         // add

if (stock.TryGetValue("book", out int qty))
    Console.WriteLine($"book: {qty}");     // book: 4

Console.WriteLine(stock.ContainsKey("desk"));   // False

foreach (var (item, count) in stock)
    Console.WriteLine($"{item} = {count}");

What is happening here:

Arrays are indexed from 0, and Length is fixed once created. Reading past the end throws IndexOutOfRangeException.
List<T> gives you Add, Remove, Count and an indexer. It is the default collection when you do not know the size up front.
stock["pen"] throws KeyNotFoundException if the key is missing. Use TryGetValue when the key might not be there, and ContainsKey just to check.
Keys in a dictionary must be unique. Assigning with stock["pen"] = ... adds or overwrites; calling Add on an existing key throws.
A foreach over a dictionary gives key and value pairs, which you can deconstruct as var (item, count).

Practice question 5: in-memory inventory

Build an in-memory inventory using a Dictionary. It must support adding stock, removing an item, updating a quantity, and a low-stock report.

Solution

var inventory = new Inventory();

inventory.Add("Keyboard", 12);
inventory.Add("Mouse", 3);
inventory.Add("Monitor", 2);
inventory.Add("mouse", 1);             // same item: names ignore case, so Mouse goes from 3 to 4
inventory.SetQuantity("Monitor", 1);
inventory.Remove("Keyboard");

Console.WriteLine($"Remove missing item: {inventory.Remove("Webcam")}");
Console.WriteLine("Low stock (5 or fewer):");
foreach (var (name, quantity) in inventory.GetLowStock(threshold: 5))
{
    Console.WriteLine($"  {name}: {quantity}");
}

Console.WriteLine("All items:");
foreach (var (name, quantity) in inventory.GetAll())
{
    Console.WriteLine($"  {name}: {quantity}");
}

public class Inventory
{
    private readonly Dictionary<string, int> _stock = new(StringComparer.OrdinalIgnoreCase);

    public void Add(string name, int quantity)
    {
        ArgumentException.ThrowIfNullOrWhiteSpace(name);
        ArgumentOutOfRangeException.ThrowIfNegativeOrZero(quantity);

        name = name.Trim();
        _stock[name] = _stock.GetValueOrDefault(name) + quantity;
    }

    public bool Remove(string name) => _stock.Remove(name.Trim());

    public bool SetQuantity(string name, int quantity)
    {
        ArgumentOutOfRangeException.ThrowIfNegative(quantity);

        name = name.Trim();
        if (!_stock.ContainsKey(name)) return false;

        _stock[name] = quantity;
        return true;
    }

    public List<(string Name, int Quantity)> GetLowStock(int threshold = 5)
    {
        var low = new List<(string Name, int Quantity)>();
        foreach (var (name, quantity) in _stock)
        {
            if (quantity <= threshold) low.Add((name, quantity));
        }
        low.Sort((a, b) => a.Quantity.CompareTo(b.Quantity));
        return low;
    }

    public List<(string Name, int Quantity)> GetAll() =>
        _stock.OrderBy(p => p.Key).Select(p => (p.Key, p.Value)).ToList();
}

Output:

Remove missing item: False
Low stock (5 or fewer):
  Monitor: 1
  Mouse: 4
All items:
  Monitor: 1
  Mouse: 4

Why this is the best way to write it:

A Dictionary fits because the question is always "how many of this item?". A List would scan every element on each lookup; the dictionary jumps straight to the answer.
StringComparer.OrdinalIgnoreCase is set once, in the constructor. "Mouse" and "mouse" are the same item everywhere, with no scattered ToLower() calls.
The dictionary is private readonly and wrapped in an Inventory class. Callers can only change stock through methods that validate the input, so a negative quantity can never get in.
Add-or-top-up is one line: _stock[name] = _stock.GetValueOrDefault(name) + quantity. The same call works for a new item and for an existing one.
Failure is reported in the return value. Remove and SetQuantity return a bool for the normal case "that item does not exist", while the ThrowIf... guard helpers throw only for genuinely invalid arguments such as a blank name or a negative quantity.
The report returns data, not text. GetLowStock returns a list of tuples sorted by quantity and leaves printing to the caller, so the same method can feed a console, a file or a web page later.
The threshold has a default value, and the call site uses a named argument (threshold: 5), pulling in concepts 3 and 4 as well.

Five classic Day 1 mistakes

Each one follows the same pattern: what people write, why it hurts, what to write instead.

Integer division. double half = 7 / 2; gives 3. Both sides are int, so the division is done before the assignment. Write 7 / 2.0 or (double)7 / 2.
double for money. 0.1 + 0.2 == 0.3 is False. Use decimal for prices and balances, and compare double values with a tolerance.
String concatenation in a loop. result += item; copies the whole string every pass, which turns a loop into quadratic work. Use StringBuilder.
int.Parse on user input. It throws a FormatException on anything that is not a number. Use int.TryParse and handle false.
Indexing a dictionary blindly. stock["desk"] throws KeyNotFoundException when the key is missing. Use TryGetValue, or GetValueOrDefault when a default is fine.

Key lessons

Every variable has a fixed type; widening conversions are implicit, narrowing ones need an explicit cast
Use TryParse for anything a user types, and decimal for money
Strings are immutable; build them in loops with StringBuilder
Compare text with a StringComparison instead of lower-casing both sides
Pick the loop that matches the question: for for an index, foreach for each item, while for an unknown count
A switch expression returns a value and replaces most if/else ladders
Keep logic in small methods that take values in and return values out, away from Console calls
Prefer tuples over out for new code; use the Try pattern when failure is a normal outcome
List<T> for ordered sequences, Dictionary<K,V> for lookups by key
Wrap a collection in a class so every change goes through validation

Summary

Day 1 is the language core: the types you store data in, the strings you display it with, the control flow that decides what happens next, the methods that package it, and the collections that hold it. The five practice projects each stretch more than one idea at once, which is the point: real programs never use one concept at a time. If you can write all five from a blank file, you are ready for Day 2: classes, inheritance, interfaces, exceptions, null handling and file I/O.

Entity Framework Core and DbContext Explained: What It Is, How It Tracks Changes, and the Mistakes That Slow Every App Down

Manohari Jayachandran — Sun, 18 Oct 2026 16:35:18 +0000

Why this post exists

Entity Framework Core is the data layer of most .NET applications, and it is also where most .NET performance problems live. Almost all of them trace back to one object that people use daily and rarely understand: the DbContext. This post explains what it is, what it does behind the scenes, and the mistakes that follow when it is misunderstood.

What Entity Framework Core is

Entity Framework Core (EF Core) is an object-relational mapper, or ORM. It translates between two worlds that do not speak the same language: C# objects on one side, SQL tables and rows on the other.

The analogy: a translator at a meeting. You speak C# (classes, properties, LINQ). The database speaks SQL. EF Core sits between you, turning db.Customers.Where(c => c.Name == "Asha") into a SELECT statement, and turning the rows that come back into Customer objects.

The tradeoff: you write far less data-access code and get compile-time checking, but you give up direct control of the SQL. Usually that is a good deal. It becomes a bad one when you do not look at what SQL is being generated.

What a DbContext is

The DbContext is the main class you work with in EF Core. A common mistake is to treat it as a database connection or as a global gateway to the database. It is neither.

The analogy: a clerk at a warehouse counter, holding a clipboard. You ask the clerk for items (queries). The clerk fetches them and writes down on the clipboard exactly what was handed over and what it looked like (the change tracker). You then change some items, add new ones, discard others. Nothing in the warehouse changes yet. When you say "submit", the clerk reads the clipboard, works out what is different, and makes one trip to the warehouse to apply everything together (SaveChanges).

That gives the DbContext three jobs:

Query: turns LINQ into SQL and runs it.
Track: remembers every entity it loaded, and the state each one was in when loaded.
Unit of work: SaveChanges writes all the tracked changes as a single transaction.

The word that matters in all of this is short-lived. The clerk's clipboard is for one job. Hand the same clipboard around all day and it fills up, gets out of date, and eventually two people write on it at once.

The example: customers and orders

One small model used throughout: a customer has many orders.

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; } = "";
    public List<Order> Orders { get; set; } = new();
}

public class Order
{
    public int Id { get; set; }
    public int CustomerId { get; set; }
    public Customer? Customer { get; set; }
    public decimal Amount { get; set; }
    public DateTime CreatedUtc { get; set; }
}

These are plain C# classes, called entities. Each becomes a table. Id is the primary key by convention, and CustomerId is the foreign key to Customer.

The DbContext:

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options)
        : base(options) { }

    public DbSet<Customer> Customers => Set<Customer>();
    public DbSet<Order> Orders => Set<Order>();

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Entity<Customer>()
            .Property(c => c.Name).HasMaxLength(200).IsRequired();

        modelBuilder.Entity<Order>()
            .Property(o => o.Amount).HasPrecision(18, 2);
    }
}

Piece by piece: it inherits from DbContext. The constructor takes DbContextOptions, which carries the provider and connection string, so the class itself never hard-codes either. Each DbSet is a shelf in the warehouse: one per table you want to query. OnModelCreating is where you describe details the conventions cannot guess, such as maximum lengths and decimal precision.

Registering it in Program.cs

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

AddDbContext registers AppDbContext with a Scoped lifetime by default. That means one instance per web request (or one per function invocation in Azure Functions). When a controller or service asks for AppDbContext in its constructor, the container supplies the instance for that request. When the request ends, the context is disposed. That default is correct, and the next section explains why.

For Azure SQL in production, keep the connection string in configuration, not code: an app setting, a Key Vault reference, or a passwordless connection using Managed Identity.

Why DbContext must be Scoped

It is not thread-safe. Two operations using the same context at the same moment will throw or corrupt state.
The change tracker only grows. A long-lived context keeps references to every entity it ever loaded, so memory climbs.
Stale data. A tracked entity is not refreshed from the database, so a long-lived context keeps showing old values.
One unit of work. A request is naturally one unit of work. SaveChanges at the end saves everything or nothing.

Registering it as Singleton, or storing it in a static field, breaks all four. It is also the root of the captive dependency bug covered in my Azure Functions dependency injection post: a Singleton repository holding on to a Scoped DbContext.

Querying: LINQ becomes SQL

var recent = await db.Orders
    .Where(o => o.CreatedUtc > DateTime.UtcNow.AddDays(-7))
    .OrderByDescending(o => o.CreatedUtc)
    .Take(20)
    .ToListAsync();

Nothing runs until ToListAsync. Before that, the expression is an IQueryable, a description of a query. When you materialise it, EF Core generates one SQL statement with the WHERE, ORDER BY and TOP, and only the matching rows come back. This is deferred execution, and it is why the order of your LINQ calls matters: everything before ToListAsync becomes SQL, everything after runs in memory.

The change tracker and entity states

Each entity the context knows about has a state:

Detached: the context knows nothing about it.
Added: new, will be INSERTed on save.
Unchanged: loaded, nothing different yet.
Modified: loaded, then changed, will be UPDATEd.
Deleted: will be DELETEd.

var order = await db.Orders.FirstAsync(o => o.Id == 42);   // Unchanged
order.Amount = 120.00m;                                      // now Modified

db.Orders.Add(new Order { CustomerId = 1, Amount = 30m,
                          CreatedUtc = DateTime.UtcNow });   // Added

await db.SaveChangesAsync();   // one transaction: 1 UPDATE + 1 INSERT

Steps behind that: the clerk fetched order 42 and noted its original values. You changed Amount. Calling SaveChangesAsync, the clerk compared the clipboard with the current values, found one changed property, and generated an UPDATE touching only the Amount column. The new order became an INSERT. Both ran in one transaction, so either both succeed or neither does.

Tracking versus AsNoTracking

Tracking has a cost: memory for the snapshot, and time for comparison. If you only read, you do not need it.

var orders = await db.Orders
    .AsNoTracking()
    .Where(o => o.CustomerId == customerId)
    .ToListAsync();

With AsNoTracking() the clerk hands over the items without writing on the clipboard. It is faster and lighter. The catch: changes to those objects are not saved, because nobody is watching them. Use it for every read-only endpoint.

Bad version versus good version: five mistakes

Each mistake follows the same pattern: the bad version, the issues, the good version.

Mistake 1: the N+1 query

Bad version:

[HttpGet("summaries")]
public async Task<IActionResult> GetSummaries()
{
    var customers = await _db.Customers.ToListAsync();   // 1 query

    var result = new List<object>();
    foreach (var c in customers)
    {
        var count = await _db.Orders
            .CountAsync(o => o.CustomerId == c.Id);      // N queries
        result.Add(new { c.Name, OrderCount = count });
    }
    return Ok(result);
}

Issues:

One query for the customers plus one more for each customer. With 500 customers that is 501 round trips to the database.
Every customer is loaded and tracked even though only the name is used.
It looks harmless in development with five rows, and falls over in production.

Good version:

public record CustomerSummary(int Id, string Name, int OrderCount, decimal TotalAmount);

[HttpGet("summaries")]
public async Task<IActionResult> GetSummaries()
{
    var result = await _db.Customers
        .AsNoTracking()
        .Select(c => new CustomerSummary(
            c.Id,
            c.Name,
            c.Orders.Count,
            c.Orders.Sum(o => o.Amount)))
        .ToListAsync();

    return Ok(result);
}

A single query, a join and aggregates done by the database, and only four columns come back. If you genuinely need whole entities with their children, use .Include(c => c.Orders), which also loads in one query. Prefer projection when you only need some fields.

Mistake 2: filtering in memory

Bad version:

var big = (await _db.Orders.ToListAsync())
    .Where(o => o.Amount > 1000)
    .ToList();

Issues:

ToListAsync runs first, so every row in the table is pulled across the network and tracked.
The Where then runs in application memory.
It works on a small table and quietly becomes a memory and speed problem as the table grows.

Good version:

var big = await _db.Orders
    .AsNoTracking()
    .Where(o => o.Amount > 1000)
    .ToListAsync();

The Where is now part of the SQL, so the database does the filtering and only the matching rows travel.

Mistake 3: a shared context across parallel tasks

Bad version:

var tasks = ids.Select(id => _db.Orders.FirstAsync(o => o.Id == id));
var orders = await Task.WhenAll(tasks);

Issues:

All the queries start at once on one DbContext.
DbContext is not thread-safe, so EF Core throws an error that a second operation started before the first completed.
It fails unpredictably, depending on timing.

Good version:

var orders = await _db.Orders
    .AsNoTracking()
    .Where(o => ids.Contains(o.Id))
    .ToListAsync();

One query with an IN clause. If you truly need parallel work, give each task its own context from IDbContextFactory<AppDbContext>.

Mistake 4: SaveChanges inside a loop

Bad version:

foreach (var dto in newOrders)
{
    _db.Orders.Add(new Order { CustomerId = dto.CustomerId,
        Amount = dto.Amount, CreatedUtc = DateTime.UtcNow });
    await _db.SaveChangesAsync();     // one trip per order
}

Issues:

One database round trip and one transaction per order.
If the loop fails halfway, some orders are saved and some are not.
It throws away the unit-of-work idea the DbContext exists for.

Good version:

var orders = newOrders.Select(dto => new Order
{
    CustomerId = dto.CustomerId,
    Amount = dto.Amount,
    CreatedUtc = DateTime.UtcNow
});

_db.Orders.AddRange(orders);
await _db.SaveChangesAsync();     // one transaction, all or nothing

EF Core batches the INSERTs into as few round trips as it can and wraps them in one transaction.

Mistake 5: a long-lived DbContext

Bad version:

builder.Services.AddSingleton<AppDbContext>();   // or a static field

Issues:

Every request shares one context, so concurrent requests collide.
The change tracker accumulates every entity ever loaded, so memory keeps rising.
Entities become stale because tracked objects are not refreshed.
A failed SaveChanges leaves bad tracked state that affects later requests.

Good version:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("Default")));

Scoped by default: a fresh clerk and a clean clipboard for every request. If you must use a context from a Singleton, inject IDbContextFactory<AppDbContext> and create a short-lived context for each operation.

Every issue at a glance

N+1: one query per row instead of one query overall
N+1: whole entities loaded and tracked when only a few columns are needed
N+1: invisible in development, painful in production
In-memory filtering: the whole table crosses the network
In-memory filtering: Where runs in application memory
In-memory filtering: gets worse as the table grows
Shared context across tasks: concurrent operations on one context
Shared context across tasks: DbContext is not thread-safe
Shared context across tasks: timing-dependent failures
SaveChanges in a loop: a round trip and transaction per item
SaveChanges in a loop: partial saves on failure
SaveChanges in a loop: ignores the unit of work
Long-lived context: concurrent requests collide
Long-lived context: memory grows through the change tracker
Long-lived context: stale entities
Long-lived context: failed saves poison later requests

Migrations: changing the database safely

When your entities change, the database must change with them. A migration is a C# file describing that change, generated by comparing your model with the last snapshot.

dotnet ef migrations add AddOrderCreatedUtc
dotnet ef database update

The first command creates the migration. The second applies pending migrations to the database named in your connection string. That is fine for local development.

For production, avoid running Database.Migrate() at application startup. In a scaled-out app, several instances may try to migrate at the same time, and a failed migration takes the whole app down with it. Instead, generate a script and review it:

dotnet ef migrations script --idempotent -o migrate.sql

The idempotent script only applies migrations that have not been applied, so it is safe to run more than once. Run it from your pipeline as its own step, before the new version of the app starts. Also remember that dropping or renaming a column is a destructive change: deploy in two steps so the old app version keeps working while the new one rolls out.

Bulk updates without loading

Changing many rows by loading them all into the tracker is wasteful. For bulk changes, EF Core can run a single UPDATE or DELETE directly:

await _db.Orders
    .Where(o => o.CreatedUtc < DateTime.UtcNow.AddYears(-3))
    .ExecuteDeleteAsync();

Notice what is missing: no entities loaded, no tracking, no SaveChanges. The statement executes immediately, so use it deliberately.

Testing code that uses DbContext

You have two honest options. Put the data access behind a repository interface and mock it for unit tests of business logic, as in my repository pattern post. And for tests that check the queries themselves, use a real database engine, for example SQLite in memory or a disposable SQL Server container. The EF Core InMemory provider is tempting, but it does not behave like a relational database: it ignores constraints and does not translate queries to SQL, so tests can pass when production would fail.

Problem scenario and strategy

The problem: an API endpoint listing customers with order totals takes eight seconds in production. It was fast in development.

The strategy:

Turn on SQL logging, or look at the dependency calls in Application Insights, and count the queries one request makes.
Spot the pattern: one query, then the same query repeated once per customer. That is N+1.
Check whether anything is filtered after ToList. If yes, move the Where before it.
Replace the loop with a single projection using Select, returning a small DTO.
Add AsNoTracking, since the endpoint is read-only.
Check the database for an index on the foreign key and on any column filtered often. Foreign keys get one by convention, but verify.
Re-test with production-sized data and compare the query count and time. Eight seconds becomes milliseconds.

Key lessons

EF Core translates between C# objects and SQL; look at the SQL it generates
DbContext is a short-lived unit of work with three jobs: query, track, save
Changes are only written when SaveChanges is called, in one transaction
Register DbContext as Scoped; never Singleton or static
DbContext is not thread-safe: one operation at a time, or use IDbContextFactory
Use AsNoTracking for read-only queries
Avoid N+1 with projection or Include
Keep Where before ToListAsync so the database filters
Batch changes and call SaveChanges once
Apply migrations from a reviewed, idempotent script in production

Summary

The DbContext is a clerk with a clipboard: it fetches, remembers what it handed out, notices changes, and submits them together. Keep it short-lived and scoped, read with AsNoTracking, let the database do the filtering and aggregating, save in batches, and treat migrations as a deployment step rather than a startup side effect. Most EF Core performance problems stop being mysterious once you see the SQL behind the LINQ.

More on these topics: C# posts · SQL posts

Dependency Injection in Azure Functions with C#: The Isolated Worker Model, Explained

Manohari Jayachandran — Mon, 12 Oct 2026 15:59:52 +0000

Why this post exists

Most production problems in Azure Functions are not logic bugs. They are lifetime bugs: an HttpClient created on every call, a Singleton quietly holding a Scoped object, a "shared" service that is not actually shared. All of them come from the same gap, which is not knowing how dependency injection works inside a function app. This post closes that gap using one complete order-processing example.

In-process versus isolated worker

Think of a building. An in-process function app plugs into the host's own wiring. It shares the host's power supply, so it also shares the host's limits, including which .NET version and package versions it can use. An isolated worker app has its own power supply: it runs as a separate process, with its own Program.cs, its own dependency container and its own choice of .NET version.

Important date: Microsoft ends support for the in-process model on November 10, 2026. .NET 8 support also ends that date. Functions 4.x isolated supports .NET 10, 9, 8 and .NET Framework 4.8. For anything new, use the isolated worker model. Everything below assumes it.

The Program.cs of a Functions app

In the isolated model you write the entry point yourself. This is where dependency injection starts: you register services, the host builds the container once, and every function can ask for those services.

var host = new HostBuilder()
    .ConfigureFunctionsWorkerDefaults()
    .ConfigureServices((context, services) =>
    {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();

        services.Configure<OrderProcessingOptions>(
            context.Configuration.GetSection("OrderProcessing"));

        services.AddScoped<IOrderRepository, OrderRepository>();
        services.AddScoped<INotificationSender, EmailNotificationSender>();
    })
    .Build();

host.Run();

Newer templates also offer a builder style that looks like an ASP.NET Core minimal app:

var builder = FunctionsApplication.CreateBuilder(args);

builder.ConfigureFunctionsWebApplication();

builder.Services.AddScoped<IOrderRepository, OrderRepository>();
builder.Services.AddScoped<INotificationSender, EmailNotificationSender>();

builder.Build().Run();

Both do the same job. Use whichever your template generated.

Logging note: with Application Insights enabled in isolated mode, a default filter hides anything below Warning, so your LogInformation calls may not appear. Remove that rule:

.ConfigureLogging(logging =>
{
    logging.Services.Configure<LoggerFilterOptions>(options =>
    {
        var rule = options.Rules.FirstOrDefault(r => r.ProviderName ==
            "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
        if (rule is not null) options.Rules.Remove(rule);
    });
})

The example: processing orders from Service Bus

Orders arrive as JSON messages on a Service Bus queue called incoming-orders. The function validates the order, saves it, and sends a confirmation. Three things need injecting: a repository, a notification sender, and settings.

The model, options and interfaces

public record Order(string Id, string CustomerEmail, decimal Amount);

public class OrderProcessingOptions
{
    public decimal MaxOrderAmount { get; set; } = 100000m;
}

public interface IOrderRepository
{
    Task SaveAsync(Order order);
}

public interface INotificationSender
{
    Task SendAsync(string recipient, string message);
}

The function class

public class ProcessOrderFunction
{
    private static readonly JsonSerializerOptions JsonOptions =
        new() { PropertyNameCaseInsensitive = true };

    private readonly IOrderRepository _orderRepository;
    private readonly INotificationSender _notificationSender;
    private readonly OrderProcessingOptions _options;
    private readonly ILogger<ProcessOrderFunction> _logger;

    public ProcessOrderFunction(
        IOrderRepository orderRepository,
        INotificationSender notificationSender,
        IOptions<OrderProcessingOptions> options,
        ILogger<ProcessOrderFunction> logger)
    {
        _orderRepository = orderRepository;
        _notificationSender = notificationSender;
        _options = options.Value;
        _logger = logger;
    }

    [Function("ProcessOrder")]
    public async Task Run(
        [ServiceBusTrigger("incoming-orders", Connection = "ServiceBusConnection")]
        string message)
    {
        var order = JsonSerializer.Deserialize<Order>(message, JsonOptions)
            ?? throw new InvalidOperationException("Message body was not a valid order.");

        if (order.Amount <= 0 || order.Amount > _options.MaxOrderAmount)
            throw new InvalidOperationException($"Order {order.Id} amount is out of range.");

        await _orderRepository.SaveAsync(order);
        await _notificationSender.SendAsync(order.CustomerEmail, $"Order {order.Id} received.");

        _logger.LogInformation("Processed order {OrderId}", order.Id);
    }
}

Notice what the function does not do: it never creates a repository, a sender or a connection itself. It asks for them in the constructor. It logs the order id, not the customer email, so personal data stays out of your logs. Throwing on a bad order lets Service Bus retry and eventually dead-letter the message, which is the behaviour you want.

How dependencies get resolved

The power-outlet analogy: the function class is a lamp, the constructor is its plug, and the registrations in Program.cs are the wiring in the walls. The lamp never builds a power station. It plugs in. Step by step:

Start: the worker process starts and runs Program.cs. Your registrations are collected in IServiceCollection, the blueprint.
Build: Build() turns the blueprint into a working container. The power is on.
A message arrives: the Functions host receives an order from incoming-orders and hands it to the worker.
Scope created: the worker creates a new scope for this one invocation.
Constructor resolved: the container sees ProcessOrderFunction needs an IOrderRepository, an INotificationSender, IOptions and ILogger. It builds each one, and anything those depend on, recursively.
Run called: Run executes with the finished object. When it returns, the scope ends and Scoped services are disposed.

Lifetimes in Functions

Transient: a new instance every time something asks. Scoped: one instance per invocation. Singleton: one instance per host instance.

That last phrase is the one people miss. When your function app scales out, Azure runs several host instances. Each has its own container, so each has its own Singleton. In the outlet analogy: a Singleton is the main electrical panel of a building, but a scaled-out app is several buildings, each with its own panel. Never use a Singleton to hold state you expect to be shared across the whole app.

A sensible default: register repositories and senders as Scoped, stateless helpers as Singleton, and use AddHttpClient for HTTP.

The HttpClient mistake

Wrong version:

[Function("CallPartner")]
public async Task Run([ServiceBusTrigger("partner-calls")] string message)
{
    using var client = new HttpClient();   // new socket every call
    var response = await client.GetAsync("https://partner.example.com/api/status");
}

Issues:

Every invocation opens new connections. Disposing the client does not release the sockets immediately, so under load you hit socket exhaustion.
The base address and headers are hard-coded inside the function.
It cannot be mocked in a unit test.

Right version:

services.AddHttpClient<IPartnerClient, PartnerClient>(client =>
    client.BaseAddress = new Uri(context.Configuration["PartnerApi:BaseUrl"]!));

PartnerClient takes an HttpClient in its constructor, and the function takes an IPartnerClient. The factory manages connection pooling and lifetimes for you.

Captive dependency in Functions

A captive dependency is a long-lived service holding on to a short-lived one.

services.AddDbContext<OrderDbContext>(...);                  // Scoped
services.AddSingleton<IOrderRepository, OrderRepository>();   // MISTAKE

The Singleton repository captures the first DbContext it receives and keeps it for the life of the host instance. Functions can run several invocations concurrently on one host instance, so they now share one DbContext, which is not thread-safe. You get random, hard-to-reproduce errors. The fix: make the repository Scoped so it gets a fresh DbContext with every invocation.

Configuration and secrets

Locally, settings live in local.settings.json, which you never commit:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "ServiceBusConnection__fullyQualifiedNamespace": "myns.servicebus.windows.net",
    "OrderProcessing__MaxOrderAmount": "100000"
  }
}

In Azure, the same names are Application Settings. The double underscore maps to the colon in configuration, so OrderProcessing_MaxOrderAmount becomes the OrderProcessing:MaxOrderAmount key that IOptions binds to. The ServiceBusConnection_fullyQualifiedNamespace form uses an identity-based connection, so the function authenticates with its Managed Identity instead of a connection string.

For genuine secrets, use a Key Vault reference as the value of an app setting:

@Microsoft.KeyVault(SecretUri=https://my-vault.vault.azure.net/secrets/PartnerApiKey/)

Your code just reads the setting. It never knows the secret lives in Key Vault.

Unit testing the function

This is the payoff. Because the function takes interfaces, a test can hand it mocks and run without Azure.

private static ProcessOrderFunction CreateFunction(
    Mock<IOrderRepository> repo, Mock<INotificationSender> sender) =>
    new(repo.Object, sender.Object,
        Options.Create(new OrderProcessingOptions { MaxOrderAmount = 1000m }),
        NullLogger<ProcessOrderFunction>.Instance);

[Fact]
public async Task Run_SavesOrderAndNotifies_WhenOrderIsValid()
{
    var repo = new Mock<IOrderRepository>();
    var sender = new Mock<INotificationSender>();
    var function = CreateFunction(repo, sender);

    await function.Run("""{"id":"ORD-1","customerEmail":"a@example.com","amount":49.99}""");

    repo.Verify(r => r.SaveAsync(It.Is<Order>(o => o.Id == "ORD-1")), Times.Once);
    sender.Verify(s => s.SendAsync("a@example.com", It.IsAny<string>()), Times.Once);
}

[Fact]
public async Task Run_Throws_AndSavesNothing_WhenAmountExceedsMaximum()
{
    var repo = new Mock<IOrderRepository>();
    var sender = new Mock<INotificationSender>();
    var function = CreateFunction(repo, sender);

    await Assert.ThrowsAsync<InvalidOperationException>(() =>
        function.Run("""{"id":"ORD-2","customerEmail":"a@example.com","amount":5000}"""));

    repo.Verify(r => r.SaveAsync(It.IsAny<Order>()), Times.Never);
    sender.Verify(s => s.SendAsync(It.IsAny<string>(), It.IsAny<string>()), Times.Never);
}

Problem scenario and strategy

The problem: an inherited function builds its own SqlConnection, HttpClient and EmailSender inside Run. Under load it throws socket errors, it cannot be tested, and the connection string is hard-coded.

The strategy:

Extract an interface for each dependency: repository, partner client, email sender.
Register each in Program.cs with the correct lifetime: Scoped for data access, AddHttpClient for HTTP.
Move credentials out of code: Managed Identity for Azure resources, Key Vault references for real secrets.
Move tunable values into an options class bound with IOptions.
Inject everything through the constructor.
Write unit tests with mocks to lock in the behaviour.
Redeploy and watch Application Insights: the socket errors disappear because connections are now pooled by the factory.

Key lessons

Use the isolated worker model: in-process support ends Nov 10, 2026
Program.cs is where registrations live, and the container is built once
Scoped means per invocation; Singleton means per host instance, not per app
Never new up HttpClient in a function: use AddHttpClient
Never let a Singleton depend on a Scoped service
Configuration binds through IOptions; secrets belong in Key Vault
Interfaces make functions unit-testable without Azure

Summary

Dependency injection in Azure Functions is the same dependency injection you know from ASP.NET Core, with two differences worth remembering: Program.cs is your responsibility in the isolated model, and a Singleton lives per host instance. Get the lifetimes right, inject through constructors, keep secrets out of code, and your functions become reliable, configurable and testable.

More on these topics: Azure posts · C# posts

ASP.NET Core Middleware: The Request Pipeline, Explained

Manohari Jayachandran — Tue, 06 Oct 2026 16:58:07 +0000

The Dependency Injection post covered the first half of Program.cs, everything on builder.Services, the registry that gets built before the app starts. This post covers the second half: everything after builder.Build(), the middleware pipeline. Lines like app.UseAuthentication() and app.MapControllers() get copied between projects constantly, usually without anyone being sure why they sit in the order they do. The Product API from earlier posts is the working example throughout.

What Middleware Actually Is

Middleware is a component that sits in the path of every HTTP request. Each one receives the request, can do some work, and then either passes the request on to the next component or stops it right there and responds itself. Together, the chain of middleware is called the request pipeline.

Think of airport security. Before you reach your gate, you pass through a series of checkpoints, passport control, a baggage scan, a boarding pass check. Each checkpoint inspects you, and each one makes a decision: wave you through to the next checkpoint, or stop you right there. If passport control rejects you, you never reach the baggage scan at all. The gate at the end is the endpoint, your controller action, and it only ever sees passengers who cleared every checkpoint before it.

The Request Goes In, and the Response Comes Back Out

A middleware component doesn't just run once. It gets a next delegate representing the rest of the pipeline. Code written before calling next() runs on the way in; code written after runs on the way back out, once everything further down the pipeline has finished.

var app = builder.Build();

app.Use(async (context, next) =>
{
    Console.WriteLine("1 - request going in");
    await next();
    Console.WriteLine("4 - response coming back out");
});

app.Use(async (context, next) =>
{
    Console.WriteLine("2 - request going in");
    await next();
    Console.WriteLine("3 - response coming back out");
});

app.MapGet("/", () => "Hello");

// Output for one request, in order:
// 1 - request going in
// 2 - request going in
//     (the endpoint runs here)
// 3 - response coming back out
// 4 - response coming back out

The first middleware registered is the first one the request hits, and the last one the response passes through. In the airport picture, that's the passenger leaving through the same checkpoints in reverse order on the way back out.

Short-Circuiting: Stopping the Request Early

If a middleware doesn't call next(), nothing after it runs. The request stops there, and that middleware writes the response itself. This is how authentication, rate limiting, and API key checks reject a request before it ever reaches a controller.

// A simple API key check. The expected key comes from
// configuration - never hardcoded in the class, the same
// rule from the CRUD post
var expectedKey = app.Configuration["ApiKey"];

app.Use(async (context, next) =>
{
    if (!context.Request.Headers.TryGetValue("X-Api-Key", out var providedKey)
        || providedKey != expectedKey)
    {
        context.Response.StatusCode = StatusCodes.Status401Unauthorized;
        await context.Response.WriteAsync("Missing or invalid API key.");
        return;   // no next() call - the pipeline stops here
    }

    await next();
});

Use vs Run vs Map

Three methods add to the pipeline, and they do genuinely different jobs.

app.Use adds middleware that receives a next delegate. It can do work, call next() to continue, or skip next() to short-circuit. It's the most common choice.
app.Run adds terminal middleware, it has no next delegate at all, so whatever reaches it ends there, and it's used for the very last step of a pipeline.
app.Map branches the pipeline, requests whose path starts with the given path go down the branch, and everything else continues on the main pipeline.

// Map branches off a separate mini-pipeline for /health
app.Map("/health", branch =>
{
    branch.Run(async context =>
        await context.Response.WriteAsync("Healthy"));
});

// Run at the end of the main pipeline - anything that
// reaches this point goes no further
app.Run(async context =>
    await context.Response.WriteAsync("End of the line."));

In the airport picture: Use is a normal checkpoint, Run is the final gate, and Map is a separate lane, say crew-only, that splits off before the main queue.

Order Matters: It Is the Behavior

Middleware runs in exactly the order it's registered, so reordering lines changes what the application actually does. A typical, correctly ordered pipeline for an API looks like this.

app.UseExceptionHandler("/error");   // 1. catch errors from everything below
app.UseHttpsRedirection();           // 2. redirect HTTP to HTTPS
app.UseStaticFiles();                // 3. serve static files early
app.UseRouting();                    // 4. work out which endpoint matches
app.UseCors();                       // 5. cross-origin rules
app.UseAuthentication();             // 6. WHO is calling?
app.UseAuthorization();              // 7. are they ALLOWED to do this?
app.MapControllers();                // 8. run the matched endpoint

Why the order is what it is.

Exception handling goes first, because an exception handler only catches exceptions thrown by middleware registered after it, put it last and it catches almost nothing, put it first and it wraps the entire pipeline.
Authentication goes before authorization, because authorization decides whether a caller is allowed to do something, and that decision depends on knowing who the caller is, which is authentication's job, the same distinction covered in the Authentication vs Authorization post on this blog.
Routing goes before the middleware that needs to know which endpoint was matched, authorization, for example, can read metadata from the matched endpoint, like an Authorize attribute, which only exists once routing has run.

This is the practical meaning of "order matters": the pipeline isn't a list of independent features, it's a sequence where each step relies on what the earlier steps already established.

Writing Custom Middleware: A Request Timing Example

Inline app.Use lambdas are fine for small things, but anything non-trivial belongs in its own class. A middleware class takes a RequestDelegate, the next step, in its constructor, and exposes an InvokeAsync method that receives the HttpContext.

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);          // everything else runs here

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

// Registered in Program.cs
app.UseMiddleware<RequestTimingMiddleware>();

This uses the before-and-after structure directly: the stopwatch starts on the way in, and the log line is written on the way back out, once the status code is actually known. Note what gets logged, method, path, status, duration. Not headers, not tokens, nothing sensitive, which is the logging lesson from the CRUD post applied to a real piece of code.

A Lifetime Gotcha That Connects Back to the DI Post

A conventional middleware class is constructed once, when the application starts, and that single instance handles every request for the app's entire lifetime. That makes it behave like a Singleton, which means anything injected through its constructor is effectively captured for the whole app lifetime too.

// WRONG - a Scoped service injected into the constructor
// of a middleware that lives for the whole app lifetime.
// This is the captive dependency problem again.
public class AuditMiddleware
{
    private readonly RequestDelegate _next;
    private readonly IProductService _productService;   // Scoped!

    public AuditMiddleware(RequestDelegate next, IProductService productService)
    {
        _next = next;
        _productService = productService;
    }
    // ...
}

// RIGHT - Scoped services go in the InvokeAsync parameters.
// They are resolved fresh, per request, by the DI container.
public class AuditMiddleware
{
    private readonly RequestDelegate _next;

    public AuditMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(
        HttpContext context,
        IProductService productService)   // resolved per request
    {
        // use productService safely here
        await _next(context);
    }
}

The rule: constructor parameters on a middleware should be things safe to hold for the app's whole lifetime, like ILogger of T or configuration. Anything Scoped goes on InvokeAsync. There is also a factory-based alternative, IMiddleware, which is registered in DI and activated per request, a reasonable option when a middleware genuinely needs several Scoped dependencies.

Global Exception Handling: The Proper Fix From the CRUD Post

The CRUD post flagged two exception problems: errors swallowed silently, and ex.ToString() returned directly to the caller, leaking the stack trace. Handling errors in a try/catch inside every controller action doesn't scale, each one handles it a little differently, and one of them will eventually get it wrong. A single exception-handling middleware, registered first, fixes this in one place.

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

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

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception ex)
        {
            // Full detail, including the stack trace, goes to the
            // LOGS - visible to the team, never to the caller
            _logger.LogError(ex,
                "Unhandled exception for {Method} {Path}",
                context.Request.Method,
                context.Request.Path);

            // If the response has already started, headers are
            // already sent and a new status code can't be set
            if (context.Response.HasStarted)
            {
                throw;
            }

            context.Response.StatusCode = StatusCodes.Status500InternalServerError;

            var problem = new ProblemDetails
            {
                Status = StatusCodes.Status500InternalServerError,
                Title = "An unexpected error occurred."
            };

            // Generic, safe message to the caller - no exception
            // text, no stack trace, no internal paths
            await context.Response.WriteAsJsonAsync(problem);
        }
    }
}

// Program.cs - registered FIRST, so it wraps everything
app.UseMiddleware<GlobalExceptionMiddleware>();
app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();

Because it's registered first, it wraps the entire pipeline: an exception thrown from authentication, a controller, a service, or the database layer all land in the same catch block. This is the structural version of the fix from the CRUD post, log the full exception internally, return only a generic message to the caller. ASP.NET Core also ships built-in options for this, app.UseExceptionHandler, and in .NET 8 and later the IExceptionHandler interface, worth knowing exist, but writing it by hand once is the clearest way to see what they're actually doing.

Problem Scenario and Solving Strategy

The problem: every controller action in the Products API has its own try/catch. Some return ex.ToString() to the caller, some swallow the error and return 200, some log and some don't. Nobody can say how long requests take, and a recent outage took hours to diagnose because the errors weren't logged consistently.

THE STRATEGY, STEP BY STEP:

Recognize this is a cross-cutting concern - error handling and timing apply to EVERY request, so they don't belong repeated inside individual controller actions
Write a GlobalExceptionMiddleware (above) that logs the full exception internally and returns a generic ProblemDetails response - and register it FIRST in the pipeline, so it wraps everything after it
Remove the per-action try/catch blocks that only existed to handle unexpected errors - the middleware now covers them, consistently
Write a RequestTimingMiddleware (above) that logs method, path, status, and duration for every request - never headers or tokens
Register both before authentication, so even rejected requests (401s) get timed and any exception thrown during authentication is still caught
Keep constructor parameters on both middleware limited to singleton-safe services (ILogger), and put any Scoped dependency on InvokeAsync, so the lifetime rule from the DI post isn't broken
The next outage now shows up in the logs with a full stack trace and the exact request that triggered it, while callers only ever see a generic 500

Key Lessons

Middleware is a chain of components each request passes through, each one can do work, pass the request on, or stop it and respond itself.

Code before await next() runs on the way in; code after it runs on the way back out, in reverse order, which is how a timing middleware can know the final status code.

Not calling next() short-circuits the pipeline, which is how authentication and API key checks reject requests before they reach a controller.

Use adds middleware that can continue or stop, Run is terminal with no next, and Map branches the pipeline for a specific path.

Order is the behavior: an exception handler only catches what's registered after it, and authentication has to come before authorization because authorization depends on knowing who the caller is.

A conventional middleware class is constructed once for the app's lifetime, so Scoped services belong on InvokeAsync, not in the constructor, the same captive dependency problem from the DI post.

A global exception middleware, registered first, replaces scattered try/catch blocks and fixes the leaked stack trace problem from the CRUD post in a single place.

Summary

The DI post explained the first half of Program.cs: a registry of services, built before the app starts. This post covers the second half: a pipeline of middleware, where every request travels in through each component and the response travels back out in reverse. Each component can pass the request along or stop it, which is how authentication rejections and API key checks work. Order isn't cosmetic, an exception handler only protects what comes after it, and authorization needs authentication to have already run. The two halves connect directly, too: a middleware instance lives for the entire app, so the lifetime rules from the DI post apply to it, and Scoped services belong on InvokeAsync. And the exception-handling lessons from the CRUD post finally get a proper home: one middleware, registered first, logging everything internally and returning only a generic error to the caller.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Dependency Injection in .NET: The Complete Mechanics

Manohari Jayachandran — Fri, 02 Oct 2026 16:03:59 +0000

Dependency Injection shows up in nearly every ASP.NET Core project, usually as a few lines in Program.cs that get copy-pasted without much thought about what they actually do. This post goes all the way down to the real mechanics, what IServiceCollection actually is, what BuildServiceProvider does at the moment it runs, and exactly where and how a dependency gets resolved and handed to a class, using the Product API from earlier posts as the working example throughout.

The Core Idea, With an Analogy

Dependency Injection, DI, is a technique where a class receives the objects it depends on from an external source, rather than creating them itself. The class declares what it needs, usually via its constructor, and something else, the DI container, is responsible for actually supplying it.

Think of a lamp and a power outlet. A lamp doesn't generate its own electricity, and it doesn't wire itself directly into the building's breaker box, it just has a standard plug, and trusts that something on the other end of the wall will supply power the moment it's plugged in. The lamp never needs to know where that electricity actually comes from, or how it got there. A class using DI is the lamp; its constructor is the plug; the DI container is the electrical system supplying whatever gets requested, from wherever it's actually sourced.

This analogy carries through the entire rest of this post, every piece of DI's mechanics maps onto some part of this same electrical picture.

One more piece worth adding here: the power actually arriving at that outlet could originate from a solar farm, a hydroelectric dam, or a coal plant, the lamp has no way to tell, and no reason to care. Swap the power source behind the scenes, and every lamp in the building keeps working identically, completely unaware anything changed. This is precisely what happens when a registration is changed from AddScoped() to AddScoped(), ProductService, the "lamp" in this picture, keeps working exactly the same either way, because it only ever depended on the standard plug shape, the IProductRepository interface, never on which specific power plant was actually wired in behind it.

The Three Lifetimes: Transient, Scoped, Singleton

When you register a dependency, you also specify how long a single instance of it should live before a new one gets created. .NET's DI container offers three lifetimes, each genuinely different.

Transient means a brand new instance is created every single time it's requested, even multiple times within the same HTTP request.
Scoped means one instance is created per HTTP request, per "scope," and that same instance is reused for every class that asks for it within that one request.
Singleton means one instance is created the first time it's requested, and that exact same instance is reused for the entire remaining lifetime of the application, across every request, forever, until the app restarts.

Continuing the power outlet analogy:
Transient is like a disposable battery pack, plugged in fresh, used once, discarded, with a brand new one supplied the next time anything needs power.
Scoped is like the electricity supplied to one specific conference room for the duration of a single meeting, everyone in that room draws from the same circuit while the meeting is happening, but a new meeting gets its own fresh circuit session.
Singleton is like the building's one main electrical panel itself, there's exactly one, installed when the building was built, and every single outlet draws from that same one panel for the building's entire lifetime.

// Transient - genuinely stateless helpers, like a
// simple calculator or formatter with no stored state
builder.Services.AddTransient<IPriceFormatter, PriceFormatter>();

// Scoped - anything that should be consistent WITHIN
// one request, but not shared ACROSS requests - most
// commonly, anything wrapping a DbContext
builder.Services.AddScoped<IProductRepository, ProductRepository>();

// Singleton - genuinely shared, thread-safe state that
// should exist exactly once for the whole app, like
// an in-memory cache
builder.Services.AddSingleton<IMemoryCache, MemoryCache>();

IServiceCollection: The Registry Being Built

builder.Services in Program.cs is an instance of IServiceCollection, think of it as a list of entries, each one saying "here's an interface, and here's what concrete class, and lifetime, to use when something asks for it." Critically, at this point, nothing has actually been built yet, it's purely a registry being assembled before the application starts running.

In the outlet analogy, this is the building's electrical blueprint, drawn up before construction even starts, "this room gets its own circuit, that one shares the main panel." No wire is actually live yet. It's a plan an electrician is still writing down.

var builder = WebApplication.CreateBuilder(args);

// Every one of these lines ADDS AN ENTRY to the
// IServiceCollection - none of them actually CREATE
// an object yet
builder.Services.AddDbContext<ProductDbContext>(options =>
    options.UseSqlServer(connectionString));

builder.Services.AddScoped<IProductRepository, ProductRepository>();
builder.Services.AddScoped<IProductService, ProductService>();
builder.Services.AddControllers();

// At this exact point in the code, IServiceCollection
// holds four registration entries - and that's all it
// is: a plan, not yet a functioning container

AddTransient, AddScoped, AddSingleton: What the Call Actually Does

Each of these methods is an extension method on IServiceCollection that adds one entry to that registry, pairing an interface, or a concrete type, with how to construct it, and which of the three lifetimes to use.

builder.Services.AddScoped<IProductRepository, ProductRepository>();

// This single line records, roughly:
// "When something asks for an IProductRepository,
//  construct a ProductRepository to satisfy it,
//  and reuse that same instance for the rest of
//  THIS SPECIFIC request, but build a fresh one
//  for the next request"

// A second, related overload lets you provide the
// construction logic directly, useful when a
// dependency needs manual wiring
builder.Services.AddScoped<IProductRepository>(provider =>
{
    var context = provider.GetRequiredService<ProductDbContext>();
    return new ProductRepository(context);
});
// Here, "provider" is itself the DI container, being
// used to resolve ANOTHER dependency (ProductDbContext)
// needed to construct this one - DI resolving DI

BuildServiceProvider: The Moment the Registry Becomes Real

IServiceCollection is just a plan. Calling .Build() on the WebApplicationBuilder, which internally calls something equivalent to BuildServiceProvider(), takes that entire registry and turns it into a working IServiceProvider, an actual, functioning container capable of constructing real objects on demand.

In the outlet analogy, this is the moment construction finishes and the power actually gets turned on at the main breaker. The blueprint becomes a genuinely live electrical system, every outlet in the building is now capable of actually supplying power the instant something gets plugged into it.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<IProductRepository, ProductRepository>();
builder.Services.AddScoped<IProductService, ProductService>();
builder.Services.AddControllers();

// Before this next line: IServiceCollection, a LIST
// of registration entries. Nothing can be resolved yet.

var app = builder.Build();

// After this line: an actual, LIVE IServiceProvider
// now exists internally, genuinely capable of
// constructing a ProductService (and everything IT
// depends on) the moment something asks for one

Why this distinction matters: you can add as many registrations as you want before Build() is called, but once it's called, the container is effectively locked in for that running application. This is exactly why every builder.Services.Add...() call needs to happen before builder.Build(), never after.

Constructor Injection: Where Resolution Actually Happens

You never write new ProductService() anywhere in application code. Instead, a class simply declares what it needs via its constructor, and the DI container automatically resolves and supplies it the moment that class itself needs to be constructed, typically, for a controller, the moment an HTTP request arrives for one of its actions.

In the outlet analogy, the constructor parameter is the lamp's plug, a standard shape, declaring exactly what kind of power it expects. The lamp itself never asks where the electricity comes from, never traces the wire back to its source. It just plugs in, and power arrives, fully resolved.

public class ProductsController : ControllerBase
{
    private readonly IProductService _productService;

    public ProductsController(IProductService productService)
    {
        _productService = productService;
        // This constructor parameter is the ENTIRE
        // mechanism - nothing else needs to be written
        // anywhere for this to work correctly
    }
}

Here's what actually happens, step by step, when a request for GET /api/products arrives.

ASP.NET Core needs to construct a ProductsController to handle this request
It looks at the constructor and sees it needs an IProductService
It asks the IServiceProvider (built earlier from the registry) to resolve IProductService
The provider sees IProductService was registered as ProductService (Scoped) - it needs an IProductRepository to construct THAT
The provider recursively resolves IProductRepository too, which itself needs a ProductDbContext, which gets resolved the same way
The ENTIRE chain gets built, in the correct order, automatically, and the fully-constructed ProductsController is handed back, ready to handle the request

This recursive resolution, a dependency needing its own dependencies, resolved automatically in turn, is the actual mechanism behind everything covered in the earlier Repository Pattern and SOLID posts on this blog. Dependency Inversion is the design principle, depend on abstractions; this resolution process is literally what Dependency Injection means by "injection."

Manual Resolution: IServiceProvider.GetService, and Why You Rarely Need It

Constructor injection handles resolution automatically for nearly everything in a typical ASP.NET Core app. Occasionally, code needs to resolve something manually and directly, rather than through a constructor.

// Inside Program.cs, AFTER builder.Build(), for a
// one-off manual resolution (genuinely uncommon in
// normal request-handling code, but useful to know)
using (var scope = app.Services.CreateScope())
{
    var productService = scope.ServiceProvider.GetRequiredService<IProductService>();
    var products = await productService.GetAllAsync();
}

// CreateScope() is specifically important here - it
// creates a genuine SCOPE, so a Scoped dependency
// resolved inside it behaves correctly (one instance
// for this scope), rather than accidentally resolving
// a Scoped service directly from the root provider,
// which is a common and genuinely risky mistake

The Captive Dependency Bug, Explained at the Mechanics Level

An earlier post on this blog named the captive dependency problem, AddSingleton used for something wrapping a DbContext. Now that the actual mechanics are clear, here's precisely why it happens.

builder.Services.AddDbContext<ProductDbContext>(options => ...);
// AddDbContext registers ProductDbContext as SCOPED
// by default - one per request

builder.Services.AddSingleton<IProductRepository, ProductRepository>();
// MISTAKE: when the FIRST request ever comes in, the
// container builds a ProductRepository, which needs a
// ProductDbContext - it resolves ONE, and because
// ProductRepository itself is Singleton, that SAME
// ProductRepository instance (holding that SAME
// ProductDbContext instance) is reused for EVERY
// subsequent request, forever - the Scoped DbContext
// is permanently trapped inside a Singleton, used far
// beyond the single request it was actually designed
// to live for

This is precisely why .NET's DI container actually validates this at runtime in many configurations, and why matching a dependency's lifetime to what it actually wraps, Scoped for anything touching a per-request resource, is a correctness requirement, not just a style preference.

Key Lessons

IServiceCollection, builder.Services, is a registry of entries, pairing an interface, a concrete implementation, and a lifetime, built up before the application starts, not yet a working container.

AddTransient, AddScoped, and AddSingleton all add an entry to that same registry, differing only in which lifetime they specify.

BuildServiceProvider, triggered by builder.Build(), is the exact moment the registry transforms into a live, working IServiceProvider capable of actually constructing objects.

Constructor injection is the entire mechanism for resolution in normal application code, a class declares what it needs, and the container resolves the complete dependency chain recursively and automatically.

Manual resolution via IServiceProvider.GetService, or GetRequiredService, exists for genuine edge cases, and should always happen within a proper scope, CreateScope(), to avoid resolving a Scoped service incorrectly.

The captive dependency bug happens because a Singleton resolves its dependencies exactly once, permanently, trapping a Scoped dependency, like a DbContext, far beyond the single request it was designed to live for.

Summary

Dependency Injection in .NET has three distinct phases: building a registry, IServiceCollection, via AddTransient, AddScoped, and AddSingleton, turning that registry into a working container, BuildServiceProvider, triggered by builder.Build(), and resolving dependencies automatically through constructor injection every time a class needs to be constructed. That third phase is recursive, a dependency's own dependencies get resolved the same way, all the way down, which is the actual mechanism behind everything the SOLID and Repository Pattern posts on this blog described more conceptually. Understanding these three phases precisely is what turns "add this line to Program.cs because the tutorial said so" into a genuine, mechanical understanding of what's actually happening underneath.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Bootstrap for Blazor: Styling the Task Tracker

Manohari Jayachandran — Mon, 28 Sep 2026 20:27:31 +0000

This is the final post in the series. The Task Tracker has been built, refactored, rendered, and made interactive, genuinely working since Part 4, but visually plain, using nothing but default, unstyled HTML elements. This post applies Bootstrap directly on top of that same working Blazor app, with zero changes to the underlying logic, purely visual, closing out the series with something that actually looks presentable.

What Bootstrap Actually Is

Bootstrap is a CSS framework, a large, pre-written collection of CSS classes covering layout, spacing, colors, and common UI components, buttons, cards, navigation bars, so a page can look genuinely designed without writing custom CSS from scratch.

Think of pre-fabricated furniture versus building everything from raw lumber. Bootstrap's classes are like a well-designed furniture catalog, a specific bookshelf, a specific desk, already proportioned and finished correctly. You still arrange the room yourself, the actual layout of your page, but you're not hand-cutting and sanding every piece of wood from scratch.

Getting Bootstrap Into the Project

<!-- In the main HTML host page (index.html for Blazor
     WebAssembly, or _Layout.cshtml/App.razor's host
     page for Blazor Server) -->
<link href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel="stylesheet" />

<!-- That single line makes every Bootstrap class used
     throughout this post immediately available across
     the entire Blazor app -->

The Grid System: Rows and Columns, No Custom CSS

Bootstrap's layout is based on a 12-column grid. A row contains one or more columns, and the column widths, col-md-8, col-md-4, should add up to 12 for a clean, full-width layout.

<div class="row">
    <div class="col-md-8">
        <!-- Main content - takes 8 of 12 columns -->
    </div>
    <div class="col-md-4">
        <!-- Sidebar - takes the remaining 4 columns -->
    </div>
</div>

<!-- No manual percentage math, no custom CSS -
     just column counts that add up to 12 -->

Cards: Wrapping Each Task Properly

A card is a bordered, padded container with a consistent visual style, genuinely useful for turning a bare list into something that actually reads as a real UI element, not raw text.

<div class="card mb-2">
    <div class="card-body d-flex justify-content-between align-items-center">
        <span>Write documentation</span>
        <button class="btn btn-sm btn-outline-danger">Delete</button>
    </div>
</div>

<!-- mb-2 adds margin-bottom (spacing between cards)
     d-flex, justify-content-between, and
     align-items-center are Bootstrap's UTILITY classes -
     small, single-purpose classes for common layout
     needs, used here to put the task text and the
     Delete button on opposite ends of the same row -->

Button Variants: Replacing Plain, Unstyled Buttons

<button class="btn btn-primary">Add Task</button>
<button class="btn btn-outline-danger">Delete</button>
<button class="btn btn-outline-secondary">All</button>

<!-- btn-primary - a solid, prominent color for the
     main action (adding a task)
     btn-outline-danger - a red outline, appropriate
     for a destructive action (deleting), without being
     as visually loud as a solid red button everywhere
     btn-outline-secondary - a neutral, low-emphasis
     style, appropriate for the filter buttons, which
     aren't the primary focus of the page -->

A Navbar: Giving the App an Actual Header

<nav class="navbar navbar-dark bg-dark mb-4">
    <div class="container">
        <span class="navbar-brand mb-0 h1">Task Tracker</span>
    </div>
</nav>

<!-- navbar-dark + bg-dark gives a dark background with
     light text automatically color-adjusted for
     contrast - no manual color picking required -->

The Complete Styled Task Tracker

@page "/tasks"

<nav class="navbar navbar-dark bg-dark mb-4">
    <div class="container">
        <span class="navbar-brand mb-0 h1">Task Tracker</span>
    </div>
</nav>

<div class="container">

    <div class="row mb-3">
        <div class="col-md-9">
            <input class="form-control" @bind="newTaskDescription" placeholder="New task..." />
        </div>
        <div class="col-md-3">
            <button class="btn btn-primary w-100" @onclick="AddTask">Add Task</button>
        </div>
    </div>

    <div class="mb-3">
        @foreach (var task in FilteredTasks)
        {
            <div class="card mb-2">
                <div class="card-body d-flex justify-content-between align-items-center">
                    <div class="form-check">
                        <input class="form-check-input" type="checkbox" @bind="task.IsCompleted" />
                        @if (task.IsCompleted)
                        {
                            <s class="ms-2">@task.Description</s>
                        }
                        else
                        {
                            <span class="ms-2">@task.Description</span>
                        }
                    </div>
                    <button class="btn btn-sm btn-outline-danger" @onclick="() => DeleteTask(task)">Delete</button>
                </div>
            </div>
        }
    </div>

    <div class="btn-group">
        <button class="btn btn-outline-secondary" @onclick='() => currentFilter = "All"'>All</button>
        <button class="btn btn-outline-secondary" @onclick='() => currentFilter = "Active"'>Active</button>
        <button class="btn btn-outline-secondary" @onclick='() => currentFilter = "Completed"'>Completed</button>
    </div>

</div>

@code {
    // IDENTICAL to Part 4 - zero logic changes.
    // Every single change in this post is a class
    // attribute added to existing markup
    private List<TaskItem> tasks = new();
    private string newTaskDescription = string.Empty;
    private string currentFilter = "All";

    private IEnumerable<TaskItem> FilteredTasks => currentFilter switch
    {
        "Active" => tasks.Where(t => !t.IsCompleted),
        "Completed" => tasks.Where(t => t.IsCompleted),
        _ => tasks
    };

    private void AddTask()
    {
        if (!string.IsNullOrWhiteSpace(newTaskDescription))
        {
            tasks.Add(new TaskItem { Description = newTaskDescription, IsCompleted = false });
            newTaskDescription = string.Empty;
        }
    }

    private void DeleteTask(TaskItem task) => tasks.Remove(task);
}

Worth noticing directly: the @code block is completely unchanged from Part 4. Every single addition in this post, navbar, card, btn-primary, row and col-md classes, is a CSS class attached to existing markup. This is the practical meaning of separating structure and logic, Blazor's job, from presentation, Bootstrap's job: styling an app doesn't require touching the code that makes it actually work.

The Series, Complete

This closes the WPF, MVVM, Razor, Blazor, Bootstrap series. Part 1 built a working Task Tracker in plain WPF, honestly naming the pain points left in on purpose. Part 2 refactored that exact app into proper MVVM, fixing every one of those pain points directly, tangled logic separated, the missed-refresh bug eliminated structurally, the filtering logic made genuinely unit-testable. Part 3 pivoted to the web, rendering the same task data with Razor, deliberately read-only. Part 4 made that page interactive with Blazor, using C# instead of JavaScript, arriving at genuine feature parity with the WPF and MVVM version, add, check, delete, filter, through a completely different technology stack. Part 5, this post, finished the job visually, applying Bootstrap on top of already-working Blazor logic with zero changes to that logic at all.

One example, five posts, two genuinely different technology stacks, WPF desktop and Blazor web, built to the same functional specification, which is itself a useful thing to be able to say plainly in an interview: the same problem, solved twice, in two different paradigms, understanding what changed and what stayed conceptually the same across both.

Key Lessons

Bootstrap is a pre-written CSS framework, classes for layout, components, and utilities, letting a page look genuinely designed without writing custom CSS from scratch.

The 12-column grid system, row and col-md classes, handles layout proportions without manual percentage math.

Cards, button variants, and the navbar are pre-styled components, dropping a class onto existing markup, not building visual style from raw CSS.

Applying Bootstrap required zero changes to the Blazor @code block, proof that structure and logic and visual presentation are genuinely separable concerns.

Across this five-part series, the same Task Tracker was built twice, in WPF and MVVM, and in Razor, Blazor, and Bootstrap, the same functional requirements, two different technology stacks, each with its own idioms for solving the same underlying problems, keeping UI in sync with data, separating concerns, styling presentation.

Summary

Bootstrap turns a functionally complete but visually plain Blazor app into something genuinely presentable, using a pre-written grid system, styled components, and utility classes, all applied without touching a single line of the underlying Blazor logic. That separation is the point: the same Task Tracker that worked correctly in Part 4 works identically here, just dressed properly. Across all five posts in this series, one example carried through two genuinely different technology stacks, a plain WPF window refactored into proper MVVM, and a Razor page made interactive with Blazor and then styled with Bootstrap, arriving at the same functional result from two different directions, which is exactly the kind of comparative understanding worth having ready for an interview question about either one.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Blazor Fundamentals: Making the Task Tracker Interactive

Manohari Jayachandran — Thu, 24 Sep 2026 15:08:53 +0000

Part 3 built a read-only Task Tracker page with Razor, HTML generated from data, nothing more, deliberately. This post takes that exact same Razor syntax and adds real interactivity on top of it: adding a task, checking a box, deleting one, filtering by status, all using C#, with no JavaScript written anywhere, and no full page reload on any interaction.

What Blazor Actually Is

Blazor is a framework for building interactive web UIs using C# instead of JavaScript. It's built directly on top of Razor syntax, covered in the previous post, the same @ symbol, the same mixing of C# and HTML, with an added layer that makes the page actually respond to user interaction.

Think of Part 3's Razor page as a printed photograph, accurate, but fixed the moment it was generated. Blazor turns that into a live video call instead, the picture keeps updating in real time as things actually change, without needing to print a brand new photograph, reload the whole page, every time something happens.

Components: The Actual Building Block

A Blazor component is a .razor file that combines markup and its C# logic together in one place, genuinely different from WPF's split between a .xaml file and a separate .xaml.cs code-behind file.

@* TaskTracker.razor - markup AND logic, ONE file *@

<h2>Task Tracker</h2>

<p>@completedCount of @tasks.Count tasks completed</p>

@code {
    private List<TaskItem> tasks = new();
    private int completedCount => tasks.Count(t => t.IsCompleted);
}

<!-- The @code block contains genuine C# - fields,
     properties, methods - living directly alongside
     the markup that uses them, in the exact same file -->

Event Handling: @onclick, Wiring a Button to Real CSharp

Blazor provides directives like @onclick that wire a DOM event directly to a C# method, no JavaScript event listener setup required at all.

<input @bind="newTaskDescription" placeholder="New task..." />
<button @onclick="AddTask">Add Task</button>

@code {
    private string newTaskDescription = string.Empty;
    private List<TaskItem> tasks = new();

    private void AddTask()
    {
        if (!string.IsNullOrWhiteSpace(newTaskDescription))
        {
            tasks.Add(new TaskItem { Description = newTaskDescription, IsCompleted = false });
            newTaskDescription = string.Empty;
        }
    }
}

<!-- Clicking the button calls AddTask() directly.
     Blazor automatically re-renders whatever part of
     the page actually changed as a RESULT of that
     method running - no manual "refresh the UI" step,
     similar in spirit to what INotifyPropertyChanged
     did for WPF in the MVVM post, but handled
     automatically by the framework here instead -->

@bind: Two-Way Data Binding

@bind keeps an input element and a C# variable automatically in sync, in both directions, type into the box, the variable updates; change the variable in code, the box reflects it.

<input @bind="newTaskDescription" />

<!-- Typing into this input automatically updates
     newTaskDescription. No manual @onchange handler
     needed to read the typed value - @bind does
     both directions of the sync automatically -->

<input type="checkbox" @bind="task.IsCompleted" />

<!-- The exact same @bind directive, on a checkbox
     this time - checking or unchecking it updates
     task.IsCompleted directly, immediately -->

Blazor Server vs Blazor WebAssembly: A Genuinely Important Distinction

Blazor has two fundamentally different hosting models, and the C# code you write looks nearly identical in both, but where that code actually executes is completely different.

With Blazor Server, your C# code runs on the server. The browser holds a live connection, via SignalR, back to that server, every click, every keystroke, sends a small message to the server, which runs the actual C# and sends back only the specific UI changes needed. The advantage is a smaller initial download and full .NET access. The tradeoff is that it requires a constant, low-latency connection to the server, it doesn't work offline, and every interaction has a small network round-trip.

With Blazor WebAssembly, your C# code is compiled and runs directly inside the browser itself, via WebAssembly, no server round-trip needed for each interaction. The advantage is that it works offline once loaded, with no per-interaction network latency. The tradeoff is a larger initial download, since the .NET runtime itself has to be downloaded to the browser, and some API limitations compared to full server-side .NET.

Think of Blazor Server like a video game streamed from a powerful remote server, the actual game runs elsewhere, your screen just shows the result and sends your button presses back. Blazor WebAssembly is like downloading the entire game and running it natively on your own machine, a bigger download upfront, but no lag once it's running, and no dependency on staying connected to anything.

The Complete Interactive Task Tracker

@page "/tasks"

<h2>Task Tracker</h2>

<div>
    <input @bind="newTaskDescription" placeholder="New task..." />
    <button @onclick="AddTask">Add Task</button>
</div>

<ul>
    @foreach (var task in FilteredTasks)
    {
        <li>
            <input type="checkbox" @bind="task.IsCompleted" />
            @if (task.IsCompleted)
            {
                <s>@task.Description</s>
            }
            else
            {
                <span>@task.Description</span>
            }
            <button @onclick="() => DeleteTask(task)">Delete</button>
        </li>
    }
</ul>

<div>
    <button @onclick='() => currentFilter = "All"'>All</button>
    <button @onclick='() => currentFilter = "Active"'>Active</button>
    <button @onclick='() => currentFilter = "Completed"'>Completed</button>
</div>

@code {
    private List<TaskItem> tasks = new();
    private string newTaskDescription = string.Empty;
    private string currentFilter = "All";

    private IEnumerable<TaskItem> FilteredTasks => currentFilter switch
    {
        "Active" => tasks.Where(t => !t.IsCompleted),
        "Completed" => tasks.Where(t => t.IsCompleted),
        _ => tasks
    };

    private void AddTask()
    {
        if (!string.IsNullOrWhiteSpace(newTaskDescription))
        {
            tasks.Add(new TaskItem { Description = newTaskDescription, IsCompleted = false });
            newTaskDescription = string.Empty;
        }
    }

    private void DeleteTask(TaskItem task) => tasks.Remove(task);
}

// TaskItem.cs - a plain class, same shape as every
// previous post in this series
public class TaskItem
{
    public string Description { get; set; }
    public bool IsCompleted { get; set; }
}

Worth noticing directly: FilteredTasks is a computed property, not a method that has to be manually called after every change, Blazor automatically re-evaluates it and re-renders the list whenever any value it depends on changes, whether that's currentFilter being set by a button click, or a task's IsCompleted flipping via a checkbox. There is no manual refresh step anywhere in this file, the same category of problem the MVVM post solved for WPF, here solved automatically by the framework itself.

Comparing This to the WPF/MVVM Version

In WPF plus MVVM from Parts 1 and 2, you had a Window or UserControl; in Blazor, that's a Component, a single .razor file. WPF needed XAML plus a separate code-behind file; Blazor combines markup and @code in one file. WPF used Click="Method"; Blazor uses @onclick="Method". WPF used {Binding Property}; Blazor uses @bind="variable". WPF needed INotifyPropertyChanged with manual event wiring; Blazor re-renders automatically, handled by the framework. WPF used ICommand and RelayCommand; Blazor just calls a plain C# method directly.

The underlying goal is genuinely the same across both, keep the UI in sync with changing data, without manual refresh steps, but Blazor folds markup and logic into a single file and handles re-rendering automatically, where WPF and MVVM required more explicit, hand-written plumbing to achieve a similar result.

Key Lessons

A Blazor component combines markup and C# logic in one .razor file, genuinely different from WPF's split between XAML and a separate code-behind file.

@onclick wires a DOM event directly to a C# method, with no JavaScript event listener setup required.

@bind provides automatic two-way synchronization between an input element and a C# variable, type in the box, the variable updates; change the variable, the box updates.

Blazor Server runs C# on the server with a live connection back to the browser; Blazor WebAssembly compiles C# to run directly inside the browser itself, genuinely different tradeoffs in latency, offline support, and initial download size.

Blazor re-renders automatically when a value a component depends on changes, no manual refresh call anywhere, solving the same category of problem MVVM solved for WPF, but handled by the framework rather than hand-written.

What's Next

Part 5, the final post in this series, applies Bootstrap directly to this Blazor Task Tracker, the grid system, styled buttons, cards, and a proper navbar, turning this functional-but-plain interface into something that actually looks presentable.

Summary

Blazor takes the Razor syntax from the previous post and adds genuine interactivity on top of it, using C# instead of JavaScript throughout. Components combine markup and logic in one file. @onclick and @bind replace manual event listener setup with simple, declarative directives. And critically, Blazor handles re-rendering automatically whenever a dependent value changes, the same underlying problem MVVM solved for WPF through INotifyPropertyChanged, here solved by the framework itself rather than requiring hand-written plumbing. The choice between Blazor Server and Blazor WebAssembly is a genuine architectural decision, not a minor detail, since it determines where the actual C# code runs and what tradeoffs that brings.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

Razor Syntax Fundamentals: Rendering the Task Tracker

Manohari Jayachandran — Fri, 18 Sep 2026 14:47:55 +0000

Parts 1 and 2 covered WPF and MVVM, a desktop application built and then properly structured. Part 3 pivots to the web, genuinely new territory. Razor is the syntax Blazor, covered in Part 4, is built directly on top of, so this post covers Razor on its own first, deliberately, before any framework gets layered in, the same Task Tracker data from the previous two posts, now rendered as a simple, read-only web page.

What Razor Actually Is

Razor is a syntax for mixing C# directly into HTML, letting a single file describe both the visual structure of a page and the logic that decides what actually gets rendered, no separate templating language to learn, since the logic portions are just genuine C#.

Think of a mail-merge letter template. Most of the letter is fixed, ordinary text, but certain spots contain a placeholder, "Dear [Name]", that gets filled in with real data before the letter is actually printed. Razor works the same way: most of a .cshtml file is plain HTML, but specific spots marked with @ get replaced with real, computed values, or entire blocks of logic, before the page is actually sent to a browser.

The @ Symbol: How Razor Knows Where C# Starts

Everything in a Razor file is treated as plain HTML by default. The @ symbol is the signal that switches into C# mode for whatever comes immediately after it.

<h2>Task Tracker</h2>
<p>You have @Model.Tasks.Count tasks.</p>

<!-- Everything here is plain HTML, rendered exactly
     as written, EXCEPT @Model.Tasks.Count - that
     specific expression is evaluated in C#, and the
     RESULT (a number) is what actually appears in
     the rendered page -->

Razor is genuinely smart about where C# ends and HTML resumes again, it doesn't require an explicit closing symbol for a simple expression like this one, since it can tell from the syntax itself where the C# expression naturally ends.

Mixing C# and HTML Directly: A Small First Example

@{
    var completedCount = Model.Tasks.Count(t => t.IsCompleted);
}

<h2>Task Tracker</h2>
<p>@completedCount of @Model.Tasks.Count tasks completed</p>

<!-- The @{ } block above is a CODE BLOCK - pure C#,
     computing a value, but not directly rendering
     anything itself. The variable it creates
     (completedCount) is then USED further down,
     inside the HTML, with a simple @ expression -->

@foreach: Rendering a List

Razor supports genuine C# control structures directly inside HTML, a @foreach loop generates one copy of whatever HTML sits inside it, once per item.

<ul>
    @foreach (var task in Model.Tasks)
    {
        <li>@task.Description</li>
    }
</ul>

<!-- This is a REAL C# foreach loop - the exact same
     syntax used anywhere else in C#. The <li> element
     inside the loop body gets rendered once per task
     in Model.Tasks, with @task.Description substituted
     in each time -->

@if: Conditional Rendering

The same applies to @if and else, genuine C# conditional logic, deciding which HTML actually gets rendered.

<ul>
    @foreach (var task in Model.Tasks)
    {
        <li>
            @if (task.IsCompleted)
            {
                <s>@task.Description</s>
            }
            else
            {
                <span>@task.Description</span>
            }
        </li>
    }
</ul>

<!-- Completed tasks render inside a <s> tag
     (strikethrough) - matching visually what checking
     a box did in the WPF version from Parts 1 and 2.
     Incomplete tasks render in a plain <span> instead -->

Rendering the Complete Task Tracker as a Read-Only Page

@model TaskTrackerViewModel

<h2>Task Tracker</h2>

@{
    var completedCount = Model.Tasks.Count(t => t.IsCompleted);
}

<p>@completedCount of @Model.Tasks.Count tasks completed</p>

<ul>
    @foreach (var task in Model.Tasks)
    {
        <li>
            @if (task.IsCompleted)
            {
                <s>@task.Description</s>
            }
            else
            {
                <span>@task.Description</span>
            }
        </li>
    }
</ul>

@if (!Model.Tasks.Any())
{
    <p><em>No tasks yet.</em></p>
}

<!-- @model at the very top declares WHAT TYPE of data
     this specific Razor file expects to receive - here,
     a TaskTrackerViewModel containing a list of tasks.
     This is what makes Model.Tasks, used throughout the
     rest of the file, actually valid and known at
     compile time -->

// TaskTrackerViewModel.cs - the plain C# class this
// Razor file expects, supplied by whatever is rendering
// the page (a Razor Page or an MVC controller action)
public class TaskTrackerViewModel
{
    public List<TaskItem> Tasks { get; set; }
}

What's Deliberately Not Here Yet

This page is genuinely read-only, there's no way to add a task, check a box, or delete anything from it. That's intentional: Razor by itself describes how to render HTML from data, nothing more. The interactivity, a button that actually does something without a full page reload, a checkbox that actually updates state, is exactly what Blazor, covered in the next post, adds on top of this same Razor syntax.

Key Lessons

Razor mixes real C# directly into HTML using the @ symbol, there's no separate templating language, the logic portions are genuine, ordinary C#.

A code block computes values without directly rendering anything; a simple expression renders a value directly at that exact spot.

@foreach and @if are the exact same C# control structures used anywhere else, just usable directly inside HTML markup.

@model at the top of a file declares the exact type of data that file expects, giving compile-time knowledge of what Model actually contains throughout the rest of the file.

Razor on its own only describes how to render HTML from data, it has no interactivity by itself, which is exactly the gap Blazor fills next.

What's Next

Part 4 covers Blazor, taking this exact Razor syntax and adding real interactivity on top of it, turning the read-only Task Tracker page built here into one where adding, checking, and deleting tasks actually works, without a full page reload.

Summary

Razor lets C# and HTML live in the same file, using @ as the signal for where C# begins, a code block for computing values, a simple expression for rendering one directly, and genuine control structures like @foreach and @if for loops and conditionals. The Task Tracker rendered here is intentionally read-only, since Razor by itself only describes how to turn data into HTML, it has no concept of interactivity on its own. That gap is exactly what the next post's subject, Blazor, exists to fill, building directly on top of everything covered in this one.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

MVVM Explained: Refactoring the Task Tracker, Properly

Manohari Jayachandran — Wed, 16 Sep 2026 15:17:51 +0000

Part 1 built a working Task Tracker in plain WPF, and closed by naming three pain points left visible on purpose, business logic tangled directly with UI code, a manual refresh step that was easy to forget (and one place where it actually was forgotten), and zero ability to unit test the filtering logic without running the full application. This post refactors that exact same app into proper MVVM, fixing all three, one at a time.

What MVVM Actually Is

MVVM stands for Model-View-ViewModel, a pattern that splits an application into three distinct roles, each with exactly one job, so that UI code and business logic never end up tangled together the way they were in Part 1.

The Model is what a Task actually is, its data, Description and IsCompleted, with no UI knowledge whatsoever. The View is the XAML, purely visual, it knows how to display things, and nothing about what a "task" means or how filtering works. The ViewModel is the middleman, it holds the tasks, knows how filtering works, and exposes everything the View needs to bind to, but has no direct reference to any XAML control at all.

Think of a restaurant. The Model is the food itself, the actual dish, made of actual ingredients. The View is the plate and table setting, how it's presented to the customer, purely visual. The ViewModel is the waiter, the one who actually knows what's in the kitchen, takes the order, and carries information back and forth between the kitchen and the table, without the plate ever needing to know how the dish was cooked, and without the kitchen ever needing to know which table it's going to.

The Model: Just Data, Nothing Else

// TaskItem.cs - unchanged in SHAPE from Part 1, but now
// implements INotifyPropertyChanged, covered next
public class TaskItem : INotifyPropertyChanged
{
    private string _description;
    private bool _isCompleted;

    public string Description
    {
        get => _description;
        set { _description = value; OnPropertyChanged(); }
    }

    public bool IsCompleted
    {
        get => _isCompleted;
        set { _isCompleted = value; OnPropertyChanged(); }
    }

    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged([CallerMemberName] string name = null)
        => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
}

INotifyPropertyChanged: How the UI Finds Out Something Changed

In Part 1, updating the UI after a change required manually calling RefreshList(), a step that was easy to forget, and genuinely was forgotten in the checkbox handler. INotifyPropertyChanged fixes this at the source: whenever a property's value actually changes, it raises an event announcing exactly that. The UI, bound to that property, is listening for this event and updates itself automatically, nobody has to remember to tell it anything.

Think of a doorbell versus needing to personally walk around telling every single person in a house that someone arrived. Ring the doorbell once, raise the event, anyone who cares, anyone bound or listening, hears it and reacts automatically, without you tracking down each person individually.

The ViewModel: Where the Actual Logic Now Lives

public class TaskViewModel : INotifyPropertyChanged
{
    private ObservableCollection<TaskItem> _allTasks = new();
    private ObservableCollection<TaskItem> _visibleTasks = new();
    private string _newTaskDescription;
    private string _currentFilter = "All";

    public ObservableCollection<TaskItem> VisibleTasks
    {
        get => _visibleTasks;
        private set { _visibleTasks = value; OnPropertyChanged(); }
    }

    public string NewTaskDescription
    {
        get => _newTaskDescription;
        set { _newTaskDescription = value; OnPropertyChanged(); }
    }

    public ICommand AddTaskCommand { get; }
    public ICommand DeleteTaskCommand { get; }
    public ICommand ShowAllCommand { get; }
    public ICommand ShowActiveCommand { get; }
    public ICommand ShowCompletedCommand { get; }

    public TaskViewModel()
    {
        AddTaskCommand = new RelayCommand(AddTask);
        DeleteTaskCommand = new RelayCommand<TaskItem>(DeleteTask);
        ShowAllCommand = new RelayCommand(() => ApplyFilter("All"));
        ShowActiveCommand = new RelayCommand(() => ApplyFilter("Active"));
        ShowCompletedCommand = new RelayCommand(() => ApplyFilter("Completed"));
    }

    private void AddTask()
    {
        if (!string.IsNullOrWhiteSpace(NewTaskDescription))
        {
            var task = new TaskItem { Description = NewTaskDescription, IsCompleted = false };
            task.PropertyChanged += (s, e) => ApplyFilter(_currentFilter);
            // ^ this ViewModel LISTENS to each task's own
            // PropertyChanged - so checking a box automatically
            // re-applies the current filter, fixing the EXACT
            // bug from Part 1 where checking a box didn't
            // update the Completed filter until a button was
            // clicked again

            _allTasks.Add(task);
            NewTaskDescription = string.Empty;
            ApplyFilter(_currentFilter);
        }
    }

    private void DeleteTask(TaskItem task)
    {
        _allTasks.Remove(task);
        ApplyFilter(_currentFilter);
    }

    private void ApplyFilter(string filter)
    {
        _currentFilter = filter;
        var filtered = filter switch
        {
            "Active" => _allTasks.Where(t => !t.IsCompleted),
            "Completed" => _allTasks.Where(t => t.IsCompleted),
            _ => _allTasks.AsEnumerable()
        };
        VisibleTasks = new ObservableCollection<TaskItem>(filtered);
    }

    public event PropertyChangedEventHandler PropertyChanged;
    protected void OnPropertyChanged([CallerMemberName] string name = null)
        => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
}

Notice what's genuinely absent: no TaskListBox, no TaskInput.Text, no reference to any XAML control anywhere in this entire class. Every single method here operates purely on data and logic, which is exactly what makes it unit-testable, covered further below.

ICommand: Replacing Click Event Handlers

In Part 1, a button's Click="AddTask_Click" called a method directly in code-behind. In MVVM, a button binds to an ICommand property on the ViewModel instead, the View never calls a method directly at all.

// RelayCommand.cs - a small, reusable ICommand
// implementation (a common, standard helper class)
public class RelayCommand : ICommand
{
    private readonly Action _execute;
    private readonly Func<bool> _canExecute;

    public RelayCommand(Action execute, Func<bool> canExecute = null)
    {
        _execute = execute;
        _canExecute = canExecute;
    }

    public bool CanExecute(object parameter) => _canExecute?.Invoke() ?? true;
    public void Execute(object parameter) => _execute();
    public event EventHandler CanExecuteChanged
    {
        add => CommandManager.RequerySuggested += value;
        remove => CommandManager.RequerySuggested -= value;
    }
}

// A generic version for commands needing a parameter,
// like DeleteTaskCommand needing to know WHICH task
public class RelayCommand<T> : ICommand
{
    private readonly Action<T> _execute;
    public RelayCommand(Action<T> execute) => _execute = execute;
    public bool CanExecute(object parameter) => true;
    public void Execute(object parameter) => _execute((T)parameter);
    public event EventHandler CanExecuteChanged;
}

The View: Now Purely Visual

<Window x:Class="TaskTracker.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Task Tracker" Height="450" Width="400">

    <Window.DataContext>
        <local:TaskViewModel />
    </Window.DataContext>

    <DockPanel Margin="10">

        <StackPanel DockPanel.Dock="Top" Orientation="Horizontal" Margin="0,0,0,10">
            <TextBox Text="{Binding NewTaskDescription, UpdateSourceTrigger=PropertyChanged}" Width="250" Margin="0,0,10,0" />
            <Button Content="Add Task" Command="{Binding AddTaskCommand}" />
        </StackPanel>

        <StackPanel DockPanel.Dock="Bottom" Orientation="Horizontal" HorizontalAlignment="Center">
            <Button Content="All" Command="{Binding ShowAllCommand}" Margin="5" />
            <Button Content="Active" Command="{Binding ShowActiveCommand}" Margin="5" />
            <Button Content="Completed" Command="{Binding ShowCompletedCommand}" Margin="5" />
        </StackPanel>

        <ListBox ItemsSource="{Binding VisibleTasks}">
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <CheckBox IsChecked="{Binding IsCompleted}" />
                        <TextBlock Text="{Binding Description}" Margin="10,0,0,0" />
                        <Button Content="Delete"
                                Command="{Binding DataContext.DeleteTaskCommand,
                                          RelativeSource={RelativeSource AncestorType=Window}}"
                                CommandParameter="{Binding}"
                                Margin="20,0,0,0" />
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>

    </DockPanel>
</Window>

Notice: zero Click= or Checked= event handlers anywhere. Every interaction is a binding or a command. This XAML file has no paired logic in MainWindow.xaml.cs at all, the code-behind file is now essentially empty.

The Three Pain Points From Part 1, Fixed Directly

Pain point one was business logic tangled with UI code. This is fixed: AddTask, DeleteTask, and ApplyFilter live entirely in TaskViewModel, with zero references to any XAML control. The View contains no logic at all.

Pain point two was the manual RefreshList() that had to be remembered. This is fixed: INotifyPropertyChanged means the UI updates itself the moment VisibleTasks changes, or the moment any individual TaskItem's IsCompleted changes. There's no refresh step to forget, because there's no refresh step at all, the exact checkbox bug from Part 1 is now structurally impossible, not just fixed by remembering harder next time.

Pain point three was that the filtering logic couldn't be unit tested. This is fixed too, covered next.

The Real Payoff: Genuinely Unit-Testable Filtering Logic

public class TaskViewModelTests
{
    [Fact]
    public void ApplyFilter_Active_ReturnsOnlyIncompleteTasks()
    {
        // Arrange - no WPF, no Window, no UI of any
        // kind involved anywhere in this test
        var viewModel = new TaskViewModel();
        viewModel.NewTaskDescription = "Task A";
        viewModel.AddTaskCommand.Execute(null);
        viewModel.NewTaskDescription = "Task B";
        viewModel.AddTaskCommand.Execute(null);
        viewModel.VisibleTasks[0].IsCompleted = true;

        // Act
        viewModel.ShowActiveCommand.Execute(null);

        // Assert
        Assert.Single(viewModel.VisibleTasks);
        Assert.Equal("Task B", viewModel.VisibleTasks[0].Description);
    }
}

This is exactly the kind of test that was impossible in Part 1, filtering logic lived directly inside a Click handler, tightly coupled to TaskListBox. Here, it's plain C# logic on a plain class, tested the same way as everything covered in the earlier unit testing post on this blog.

Key Lessons

Model, View, and ViewModel each have exactly one job, data, visual presentation, and the logic connecting them, and MVVM's real value is keeping those three jobs from ever tangling back together.

INotifyPropertyChanged replaces manual refresh calls with an event the UI listens for automatically, the exact missed-refresh bug from Part 1 becomes structurally impossible, not just less likely.

ICommand replaces Click event handlers with bindable properties on the ViewModel, meaning the View never directly calls a method, it only ever binds to something.

The genuine payoff of this whole refactor is testability, the same filtering logic that required running the full WPF app and clicking buttons in Part 1 is now a plain, fast unit test with zero UI involved.

MVVM isn't extra complexity for its own sake, every piece introduced here directly fixes a specific, named problem from the plain code-behind version.

What's Next

Part 3 shifts to the web, Razor syntax fundamentals, the templating language Blazor is built on top of, covered next before Blazor itself in Part 4.

Summary

MVVM splits an app into a Model (plain data), a View (purely visual XAML), and a ViewModel (the logic connecting them, with no knowledge of any specific UI control), the restaurant analogy of dish, plate, and waiter. Refactoring the exact Task Tracker from Part 1 into this shape fixed every pain point named there directly: tangled logic separated cleanly, the missed-refresh bug eliminated structurally through INotifyPropertyChanged, and the filtering logic made genuinely unit-testable for the first time. Nothing here was added for its own sake, every piece of MVVM introduced in this post exists because a specific, real problem from the plain version needed exactly that fix.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

WPF Fundamentals: Building a Task Tracker, the Plain Way

Manohari Jayachandran — Tue, 15 Sep 2026 18:06:55 +0000

This is Part 1 of a five-part series covering WPF, MVVM, Razor, Blazor, and Bootstrap, each genuinely new territory, explained from the ground up. The example running through this post is a small Task Tracker desktop app, add a task, mark it complete, delete it, filter by status (All, Active, Completed). It's built here using plain, direct code-behind, deliberately without MVVM, the next post in the series takes this exact same app and refactors it into proper MVVM, once the specific problems with this version are visible firsthand rather than described abstractly.

What WPF Actually Is

WPF (Windows Presentation Foundation) is a framework for building desktop applications with rich, flexible user interfaces, using C# for logic and a separate markup language, XAML, to describe the visual layout.

Think of building a house. XAML is the architectural blueprint, it describes where the rooms are, how big the windows are, what the layout looks like. C# code-behind is the electrician and plumber, it makes things actually do something, a light switch that turns on a light, a button that actually adds a task, once the structure is in place.

XAML: The Markup Language, Explained

XAML (eXtensible Application Markup Language) is a declarative way to describe a user interface, what controls exist, how they're arranged, and their visual properties, separately from the C# code that gives them behavior.

<Window x:Class="TaskTracker.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Task Tracker" Height="450" Width="400">

    <Grid>
        <TextBox x:Name="TaskInput" />
        <Button Content="Add Task" Click="AddTask_Click" />
    </Grid>

</Window>

<!-- x:Name gives an element an identifier that C#
     code-behind can reference directly (TaskInput.Text,
     for example)
     Click="AddTask_Click" wires this button to a specific
     C# METHOD, written in the paired code-behind file -->

How this compares to something more familiar: XAML plays a similar role to HTML, describing structure and content declaratively, but it's specifically for a desktop window, not a browser page, and its tags map to actual .NET classes, a Button in XAML corresponds directly to the System.Windows.Controls.Button class, rather than browser-rendered HTML elements.

Windows and Controls

A Window is the actual application window itself, the outermost container. Everything else, buttons, text boxes, lists, are controls placed inside it.

TextBox is a single-line text input, where a new task's description gets typed.
Button is a clickable element, triggering a specific action when clicked, adding a task, deleting one.
ListBox displays a scrollable list of items, shows every task currently in the tracker.
CheckBox is a toggle, marks a specific task as complete or not.

Layout Panels: Three Different Philosophies

A layout panel controls how its child elements are actually arranged on screen. WPF offers several, each with a genuinely different approach.

StackPanel stacks children one after another, vertically by default or horizontally, the simplest layout, good for a straightforward list of elements in a row or column.

<StackPanel Orientation="Horizontal">
    <TextBox x:Name="TaskInput" Width="200" />
    <Button Content="Add" Click="AddTask_Click" />
</StackPanel>

Grid arranges children in rows and columns, like a table, giving precise control over exactly where each element sits.

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions>
    <StackPanel Grid.Row="0" Orientation="Horizontal">...</StackPanel>
    <ListBox Grid.Row="1" x:Name="TaskListBox" />
</Grid>

DockPanel has children that "dock" to a specific edge, top, bottom, left, right, with the last child typically filling whatever space remains.

<DockPanel>
    <StackPanel DockPanel.Dock="Top">...</StackPanel>
    <ListBox DockPanel.Dock="Bottom" />
</DockPanel>

Think of StackPanel like stacking books on a shelf, one after another. Grid is like a spreadsheet, with precise rows and columns. DockPanel is like sticky notes pressed to the edges of a whiteboard, with whatever's left in the middle.

Event Handling in Code-Behind

"Code-behind" refers to the C# file paired directly with a XAML file, MainWindow.xaml.cs, paired with MainWindow.xaml, this is where the actual logic lives, referencing controls from the XAML by their x:Name.

// MainWindow.xaml.cs
public partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
    }

    private void AddTask_Click(object sender, RoutedEventArgs e)
    {
        if (!string.IsNullOrWhiteSpace(TaskInput.Text))
        {
            TaskListBox.Items.Add(TaskInput.Text);
            TaskInput.Clear();
        }
    }
}

// AddTask_Click is wired directly to the Button's
// Click event in the XAML (Click="AddTask_Click").
// This method reaches DIRECTLY into TaskListBox and
// TaskInput - the controls defined in the XAML file -
// by their x:Name

Building the Complete Task Tracker

Here's the full XAML:

<Window x:Class="TaskTracker.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Task Tracker" Height="450" Width="400">

    <DockPanel Margin="10">

        <StackPanel DockPanel.Dock="Top" Orientation="Horizontal" Margin="0,0,0,10">
            <TextBox x:Name="TaskInput" Width="250" Margin="0,0,10,0" />
            <Button Content="Add Task" Click="AddTask_Click" />
        </StackPanel>

        <StackPanel DockPanel.Dock="Bottom" Orientation="Horizontal" HorizontalAlignment="Center">
            <Button Content="All" Click="ShowAll_Click" Margin="5" />
            <Button Content="Active" Click="ShowActive_Click" Margin="5" />
            <Button Content="Completed" Click="ShowCompleted_Click" Margin="5" />
        </StackPanel>

        <ListBox x:Name="TaskListBox">
            <ListBox.ItemTemplate>
                <DataTemplate>
                    <StackPanel Orientation="Horizontal">
                        <CheckBox IsChecked="{Binding IsCompleted}"
                                  Checked="TaskCheckBox_Changed"
                                  Unchecked="TaskCheckBox_Changed"
                                  Tag="{Binding}" />
                        <TextBlock Text="{Binding Description}" Margin="10,0,0,0" />
                        <Button Content="Delete" Click="DeleteTask_Click" Tag="{Binding}" Margin="20,0,0,0" />
                    </StackPanel>
                </DataTemplate>
            </ListBox.ItemTemplate>
        </ListBox>

    </DockPanel>
</Window>

And the full code-behind:

public partial class MainWindow : Window
{
    private List<TaskItem> _allTasks = new List<TaskItem>();

    public MainWindow()
    {
        InitializeComponent();
    }

    private void AddTask_Click(object sender, RoutedEventArgs e)
    {
        if (!string.IsNullOrWhiteSpace(TaskInput.Text))
        {
            var task = new TaskItem { Description = TaskInput.Text, IsCompleted = false };
            _allTasks.Add(task);
            TaskInput.Clear();
            RefreshList(_allTasks);
        }
    }

    private void DeleteTask_Click(object sender, RoutedEventArgs e)
    {
        var button = (Button)sender;
        var task = (TaskItem)button.Tag;
        _allTasks.Remove(task);
        RefreshList(_allTasks);
    }

    private void TaskCheckBox_Changed(object sender, RoutedEventArgs e)
    {
        var checkBox = (CheckBox)sender;
        var task = (TaskItem)checkBox.Tag;
        task.IsCompleted = checkBox.IsChecked ?? false;
    }

    private void ShowAll_Click(object sender, RoutedEventArgs e)
        => RefreshList(_allTasks);

    private void ShowActive_Click(object sender, RoutedEventArgs e)
        => RefreshList(_allTasks.Where(t => !t.IsCompleted).ToList());

    private void ShowCompleted_Click(object sender, RoutedEventArgs e)
        => RefreshList(_allTasks.Where(t => t.IsCompleted).ToList());

    private void RefreshList(List<TaskItem> tasks)
    {
        TaskListBox.ItemsSource = null;
        TaskListBox.ItemsSource = tasks;
    }
}

public class TaskItem
{
    public string Description { get; set; }
    public bool IsCompleted { get; set; }
}

The Pain Points Worth Noticing (Setting Up the Next Post)

This app genuinely works, but a few things are worth sitting with honestly, since they're exactly what the next post's MVVM refactor addresses directly.

Every single interaction is handled by code directly reaching into UI controls, TaskListBox.ItemsSource, TaskInput.Text, TaskInput.Clear(), the "business logic," what a task is, how filtering works, is tangled together with UI manipulation code in the exact same methods.

RefreshList() has to be called manually, by hand, after every single change, add a task, refresh manually; delete a task, refresh manually; check a box, forgot to refresh at all, the checkbox handler above doesn't call it, so the Completed filter won't reflect a just-checked box until you click a filter button again, a genuinely easy bug to introduce accidentally.

There is no way to unit test any of this logic in isolation, testing whether filtering to Active works correctly requires actually running the full WPF application and clicking buttons, since the filtering logic lives directly inside a Click event handler, tightly coupled to the UI itself.

Key Lessons

XAML is a declarative markup language describing WPF UI structure, playing a similar role to HTML but mapping directly to .NET classes rather than browser elements.

StackPanel, Grid, and DockPanel represent three genuinely different layout philosophies, stacking, table-like precision, and edge-docking, each suited to different UI shapes.

Code-behind directly wires XAML events to C# methods via x:Name references, straightforward, and genuinely workable for a small app like this one.

The specific pain in this version isn't that it's wrong, it's that business logic and UI manipulation code live in the exact same place, making the app harder to test and easier to introduce subtle bugs into, like the missed refresh on checkbox change, as it grows.

What's Next

Part 2 of this series takes this exact Task Tracker and refactors it into proper MVVM, separating what a task is and how filtering works, the ViewModel, from how it's actually displayed, the View, fixing the manual-refresh problem and making the filtering logic genuinely unit-testable for the first time.

Summary

WPF describes a desktop UI declaratively through XAML, with C# code-behind providing the actual behavior, referencing controls directly by name. Layout panels, StackPanel, Grid, DockPanel, offer different ways to arrange those controls on screen. The Task Tracker built here genuinely works, but every interaction reaches directly into UI controls from within event handlers, tangling business logic with UI manipulation, which is precisely the shape of problem MVVM, covered in the next post, exists to solve.

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals

GitHub Copilot for C# Developers: Setup, Techniques, Agents, and Honest Tradeoffs

Manohari Jayachandran — Thu, 10 Sep 2026 13:57:44 +0000

GitHub Copilot gets mentioned constantly and explained properly rarely, most people know "it suggests code as you type" and stop there. This post covers it from the ground up, using the Product CRUD API from earlier posts as the working example, since that domain is already familiar and lets the focus stay entirely on Copilot itself rather than a new codebase.

What GitHub Copilot Actually Is

Copilot is an AI pair programmer built into your editor, trained on a large body of public code, that suggests code based on the context of what you're currently writing. It is not one single feature, it's actually three genuinely different tools sharing one name.

Inline Suggestions show ghost text as you type, predicting the next line or few lines, press Tab to accept, Esc to dismiss. This is the original, most common form of Copilot.
Copilot Chat is a separate side panel where you ask questions, request explanations of existing code, or ask it to generate something specific through conversation.
Agent Mode is given a broader task rather than a single suggestion, and can plan, edit multiple files, and iterate somewhat autonomously toward completing that task, covered in depth further down.

Think of autocomplete on a phone keyboard, but instead of predicting the next word, it predicts the next several lines of code, based not just on what you just typed, but on the surrounding context of your open files, function names, and comments.

Setting It Up: VS Code

Open the Extensions panel (Ctrl+Shift+X)
Search for "GitHub Copilot"
Install both "GitHub Copilot" (inline suggestions) and "GitHub Copilot Chat" (the chat panel)
Sign in when prompted - this links to your GitHub account, which needs an active Copilot subscription (individual, business, or via an organization)
A small Copilot icon appears in the status bar, bottom-right - click it to confirm it's active

Once installed, ghost-text suggestions appear automatically as you type in any supported file type, including .cs files.

Setting It Up: Visual Studio

Extensions menu -> Manage Extensions
Search "GitHub Copilot"
Install, then restart Visual Studio when prompted
Sign in via the account icon, top-right corner
Copilot Chat opens as a dedicated tool window, accessible via View -> GitHub Copilot Chat

Visual Studio's integration surfaces suggestions the same way - inline, as you type - with Chat available as a separate panel for conversational requests.

Techniques That Genuinely Improve Suggestion Quality

Copilot's suggestions are only as good as the context it has to work with, specific techniques noticeably change what it suggests.

// Writing a clear comment BEFORE the code - this
// genuinely steers the next suggestion
// validate that price is greater than zero and
// stock quantity is non-negative
public bool IsValid(CreateProductDto dto)
{
    // Copilot's suggestion here is shaped directly
    // by the comment above - likely something close to:
    return dto.Price > 0 && dto.StockQuantity >= 0;
}

// Descriptive naming as a strong signal of intent
// A vague name gives Copilot little to work with:
public Task<bool> DoThing(int x) { }

// A descriptive name gives it a genuine, specific
// signal of what the method should actually do:
public Task<bool> ReserveProductStockAsync(int productId) { }
// Copilot's suggested implementation for the second
// version is noticeably more likely to match intent

Keeping related files open matters too. If ProductDto.cs, IProductService.cs, and ProductsController.cs are all open in tabs while writing a new method in ProductService.cs, Copilot's suggestions draw on the actual shape of those related types, property names, method signatures, rather than guessing at a generic, unrelated pattern.

Copilot Chat also has slash commands worth knowing:
/explain explains what a selected block of code actually does
/fix suggests a fix for a selected block with an error
/tests generates unit tests for a selected method
genuinely useful as a starting point, covered further below under the honest cons section.

What "Agent Mode" Actually Means

The terminology here is genuinely confusing right now, worth untangling directly. Inline suggestions and Chat both respond to something you've already written or asked, one piece at a time. Agent mode is given a broader, higher-level task, "implement pagination for the GetAll endpoint," and can plan the necessary steps, edit multiple files, run terminal commands, and iterate somewhat autonomously toward completing that task, checking in with you at key decision points rather than requiring line-by-line approval.

Autocomplete's scope is the next few lines, and you approve every single suggestion, constantly. Chat's scope is one specific question or request per message, and you approve by reading the response and deciding whether to use it. Agent mode's scope is a whole task, potentially spanning several files, and you approve at a higher level, reviewing a batch of changes, or specific decision points, rather than every individual line.

Why this distinction matters practically: agent mode represents a genuine shift in how much you're reviewing versus how much you're trusting the tool to get right on its own, which directly changes how carefully you need to review the eventual output.

The Genuine Pros

Speed on boilerplate is real. DTOs, basic CRUD scaffolding, repetitive patterns, the exact kind of code shown across the CRUD post's good version, Copilot genuinely speeds up writing the first draft of structurally repetitive code.

A fast first draft helps when you already know what correct looks like. Writing the general shape of a method you understand well, then reviewing and adjusting it, is often faster than typing every character by hand.

It can also be a learning aid, used deliberately. Seeing an alternative approach to something you were about to write anyway can surface a pattern or method you didn't know existed, worth treating as a suggestion to evaluate, not an answer to accept.

The Genuine Cons, Including a Real, Concrete Example

Copilot suggests code that statistically resembles patterns it has seen, including patterns that are simply wrong, if that's what surrounds it in context.

// A REAL kind of situation worth being aware of:
// if an older, unrelated file in the same project
// still contained the BAD version's pattern from the
// CRUD post -

var query = "SELECT * FROM Products WHERE Id = " + id;

// - Copilot may suggest something structurally similar
// for a NEW method, simply because that pattern exists
// elsewhere in the codebase it has as context. It does
// not independently know this is a SQL injection
// vulnerability - it's reflecting the surrounding code,
// good or bad, without judgment

A few other genuine cons, stated plainly. There's a real over-reliance risk, accepting suggestions without reading them carefully is an easy habit to fall into, especially for boilerplate that looks right at a glance. Code can be confidently wrong, a suggestion can be syntactically correct, run without error, and still be logically wrong, Copilot has no way to verify business logic correctness, only pattern plausibility. Generated tests can test the wrong thing, /tests can produce a test that passes while checking a condition that doesn't actually matter, or missing the specific failure case, like the ones covered in the unit testing post, that a human would think to add deliberately. And there are genuine licensing and originality questions, a debated topic, since suggested code is generated from patterns in public code, and questions about attribution and originality are worth being aware of, even without a settled, universal answer.

Problem Scenario and Solving Strategy

The problem: in a live coding interview, you're asked to implement a new endpoint with Copilot enabled and visible. You want to use it efficiently without appearing to not understand your own code, and without accidentally accepting a subtly incorrect suggestion under time pressure.

The strategy, step by step:

Write the method signature and a clear, specific
comment BEFORE accepting any suggestion - this alone
demonstrates you're directing the tool, not being
directed by it
Read every suggestion before accepting - out loud if
the format allows it ("this checks for null, then
queries by id... looks right, accepting that") - this
turns an invisible mental step into an audible,
visible one for an interviewer
When a suggestion looks reasonable but you're not
fully certain, say so directly: "I'd want to verify
this handles the not-found case correctly" - genuine,
visible skepticism reads as competence, not hesitation
Use Copilot for the boilerplate parts specifically
(the DTO shape, the basic CRUD structure) and slow
down deliberately for the actual business logic -
this shows judgment about WHEN the tool is
appropriate, not just that it exists
If a suggestion is wrong, say so and correct it
visibly, rather than silently accepting and moving on -
catching and fixing an incorrect suggestion in real
time is a stronger signal than never seeing one at all

Key Lessons

Copilot is three genuinely different tools under one name, inline suggestions, Chat, and agent mode, each with a different scope of autonomy and a different amount of review it actually needs from you.

Clear comments and descriptive naming aren't just good practice for human readers anymore, they're the direct input that shapes what Copilot suggests next.

Agent mode represents a real shift from approving every line to reviewing a batch of changes, worth understanding deliberately rather than treating it as just a faster version of autocomplete.

Copilot reflects the patterns already present in its context, including bad ones, it has no independent judgment about whether a pattern like string-concatenated SQL is actually safe.

The genuine skill isn't generating code quickly, it's reading generated code critically enough to know whether it's actually correct, which is exactly the skill built across the CRUD, Repository Pattern, and Unit Testing posts already on this blog.

Summary

GitHub Copilot is genuinely useful for exactly the kind of repetitive, structurally predictable code shown throughout the CRUD and Repository Pattern posts, but its suggestions are a reflection of surrounding patterns, not a judgment about correctness. Inline suggestions, Chat, and agent mode represent increasing levels of autonomy, each requiring a correspondingly different level of review. Comments and naming aren't just documentation anymore, they're the actual mechanism for getting better suggestions. And the core skill this whole blog has been building toward, understanding SOLID principles, writing testable code, knowing what a correct fix actually looks like, is precisely what makes Copilot's output genuinely useful instead of a fast way to introduce a bug you didn't write yourself.

Originally published on my blog: TechStack Blog

More from TechStack Blog: C# / .NET: https://www.techstackblog.com/category.html?cat=csharp
CS Fundamentals: https://www.techstackblog.com/category.html?cat=cs-fundamentals