Every dependency injection container, every JSON serializer, every ORM, every test runner you've used has been reading your code's own metadata back to itself, at runtime, this whole time.

Think about what actually has to happen for System.Text.Json to turn your Customer object into {"name": "Alice", "balance": 100}. Nobody wrote a line of code that says "read the Name property, then the Balance property." The serializer has never seen your Customer class before — you wrote it, it didn't. And yet it correctly discovers every public property, reads its name, reads its value, and writes it out. Or think about ASP.NET Core's dependency injection container: you register services.AddScoped<IOrderService, OrderService>(), and somehow, without you writing a single line of "new up an OrderService with these three constructor arguments," it just works — for a constructor the container has never seen before either.

Both of these are the same underlying capability: code that inspects other code's structure — its types, methods, properties — at runtime, and acts on what it finds. That capability is called reflection, and once you understand it, an enormous amount of "how does that even work" in the .NET ecosystem stops being magic.

In this lesson: what reflection actually is, the core types (Type, Assembly, MethodInfo, PropertyInfo), invoking a method dynamically, the real-world tools you've already benefited from without knowing it, and the real, measurable performance cost that motivates the next lesson.

What Is It?

The Simple Explanation

Normally, when you write customer.Withdraw(50), you know at compile time exactly which method you're calling — the compiler checked it, and the call is baked directly into the compiled code. Reflection is the opposite: it lets code ask, at runtime, "what methods does this object's type actually have?" — discovering the answer as data (a name, a list of parameters) rather than knowing it up front — and then call whichever method it found, by that discovered information, instead of by writing the method's name directly in source code.

The Technical Definition

Reflection is the ability of a .NET program to inspect its own (or another assembly's) metadata — type definitions, members, attributes — at runtime, and to dynamically create instances, get/set field and property values, and invoke methods based on that inspected information, rather than through code the compiler resolved at compile time. It's built on the fact that every compiled .NET assembly carries rich metadata describing every type and member it contains, alongside the actual executable code — the CLR (and, transitively, your program) can always read that metadata back.

Why Does It Exist?

The Problem

Some genuinely useful tools have to work with types they've never seen before, written by someone else, compiled after the tool itself. A JSON library ships as a compiled package before your Customer class even exists — it can't have a hand-written if (obj is Customer) { ... } branch for a type it doesn't know about. A dependency injection container needs to construct arbitrary services registered by application code it has no advance knowledge of. Without some way to discover a type's shape at runtime, none of that generality is possible — every such library would need the application to hand-write serialization/construction code for every single type, by hand, forever.

The Need

Developers needed a way for code to ask a type about itself — "what properties do you have, what's their name, what's their type, what constructors are available" — and then act on those answers generically, without the calling code needing to know the specific type in advance.

The Solution

The System.Reflection namespace, built directly on top of the metadata every .NET assembly already carries. Any type, any assembly, any method — known at compile time or not — can be inspected and used through a uniform set of reflection types, which is exactly what makes generic, type-agnostic infrastructure code (serializers, DI containers, ORMs, test runners) possible at all.

Big Picture

How It Works

Type type = typeof(Customer);           // compile-time known — the common case
// or, at runtime, from an instance you already have:
Customer c = new Customer();
Type sameType = c.GetType();
// or by name — the truly dynamic case, e.g. loaded from config:
Type? byName = Type.GetType("MyApp.Customer");

PropertyInfo[] properties = type.GetProperties();
MethodInfo? withdraw = type.GetMethod("Withdraw");
ConstructorInfo[] ctors = type.GetConstructors();

object? instance = Activator.CreateInstance(type); // calls a matching constructor dynamically

PropertyInfo? balanceProp = type.GetProperty("Balance");
object? currentBalance = balanceProp?.GetValue(instance);   // reads the property
balanceProp?.SetValue(instance, 500m);                      // writes the property

withdraw?.Invoke(instance, [50m]);                           // calls the method dynamically

Simple Example

public class Customer
{
    public string Name { get; set; } = "";
    public decimal Balance { get; set; }
    public void Withdraw(decimal amount) => Balance -= amount;
}

var customer = new Customer { Name = "Alice", Balance = 100m };
Type type = customer.GetType();

// Discover and print every public property, generically — works for ANY type, not just Customer
foreach (PropertyInfo prop in type.GetProperties())
{
    object? value = prop.GetValue(customer);
    Console.WriteLine($"{prop.Name} = {value}");
}
// Name = Alice
// Balance = 100

// Discover and call a method by name, with an argument
MethodInfo? withdraw = type.GetMethod("Withdraw");
withdraw?.Invoke(customer, [30m]);
Console.WriteLine(customer.Balance); // 70

Meaning: None of this code mentions Name, Balance, or Withdraw as compile-time-known identifiers — the property-printing loop, in particular, would print the exact same way for a completely different class with completely different properties, unchanged. That's the entire point: this code is generic over any type, discovered at runtime.

Real-World Example

You've used at least four tools built directly on reflection, likely without ever opening their source:

A small illustration of the DI-container pattern, built from the same pieces you just used above:

public class SimpleContainer
{
    private readonly Dictionary<Type, object> _instances = [];
    public void Register<TService>(TService instance) => _instances[typeof(TService)] = instance!;

    public object CreateWithDependencies(Type implementationType)
    {
        ConstructorInfo ctor = implementationType.GetConstructors()[0]; // (simplified — real containers pick more carefully)
        object?[] args = ctor.GetParameters()
            .Select(p => _instances[p.ParameterType])
            .ToArray();
        return ctor.Invoke(args); // constructs the object, supplying discovered dependencies automatically
    }
}

// Register the pieces OrderService needs, without OrderService's constructor being hard-coded anywhere here
var container = new SimpleContainer();
container.Register<ILogger>(new ConsoleLogger());
var orderService = (OrderService)container.CreateWithDependencies(typeof(OrderService));

This is a deliberately simplified sketch, but it's the genuine shape of what a real DI container does: reflect over a constructor's parameters, resolve each one, and invoke the constructor — for any type you register, without the container ever being written against that specific type.

Analogy

Under the Hood

Common Confusion

1. Reflection is not the same thing as dynamic

dynamic (covered in earlier modules) defers type checking and member resolution to runtime automatically, with syntax that reads exactly like normal member access — the compiler quietly generates reflection-like lookup code behind the scenes for you. Reflection is the explicit, lower-level API you call yourself (GetMethod, Invoke) to do that lookup and invocation directly. dynamic is, in a real sense, built on the same underlying dynamic-dispatch machinery reflection exposes — just with friendlier syntax hiding the mechanics.

2. Reflection can access private members too — and that has real implications

Passing BindingFlags.NonPublic | BindingFlags.Instance to member-lookup calls lets reflection read or invoke private fields, properties, and methods, bypassing normal access-modifier enforcement entirely. This is genuinely useful for certain testing/tooling scenarios, but it also means "private" is a compile-time-only barrier from reflection's point of view — worth knowing before assuming a private member is truly unreachable from outside its class.

3. "Slow" doesn't mean "never use it" — it means "know where you're using it"

Reflection's overhead is real, but it's routinely and correctly used in exactly the places this lesson describes — application startup, DI container configuration, one-time attribute scanning — where it runs a small, bounded number of times rather than in a hot loop. The problem is specifically reflection running on every iteration of a hot path, not reflection existing in a codebase at all.

Common Mistakes

Mistake 1 — Calling GetMethod/GetProperty repeatedly inside a hot loop

//  re-discovers the same MethodInfo on every single item — wasted lookup work every iteration
foreach (var item in millionsOfItems)
{
    item.GetType().GetMethod("Process")?.Invoke(item, null);
}

Look the member up once outside the loop (if all items share a type), or cache MethodInfo/PropertyInfo results keyed by type — the lookup itself is repeatable work you don't need to redo for every element.

Mistake 2 — Assuming a member always exists and skipping the null check

type.GetMethod("Withdraw").Invoke(customer, [50m]); — GetMethod returns null, not an exception, when no matching member is found; this compiles but throws a NullReferenceException at runtime for the smallest typo in the method name.

Always check for null (or use the null-conditional ?.) after a reflection lookup — there's no compile-time safety net here, unlike an ordinary method call the compiler would have rejected outright for a typo.

Mistake 3 — Reaching for reflection when a simpler, statically-typed tool already solves the problem

Using reflection to call a method you actually know about at compile time, just because it feels more "flexible." If you know the type and member at compile time, call it directly — an interface, a delegate, or generics (covered earlier in this Advanced tier) almost always solves the same problem with better performance and full compile-time checking. Reflection earns its place specifically when the type genuinely isn't known until runtime.

When Should I Use It?

• Building infrastructure that must work with types it can't know about in advance — a serializer, a DI container, a plugin system, a test runner.
• One-time or startup-time scanning — discovering all types carrying a certain attribute, resolving a small, bounded number of dependencies once when an application boots.
• Tooling and diagnostics — inspecting an object's shape for debugging, logging, or generic display purposes.
• Avoid it in hot paths — request-per-request logic in a high-throughput API, tight numeric loops, anything called many times per second — where the per-call overhead genuinely adds up; reach for direct calls, interfaces, delegates, or source generators (next lesson) instead.

Mental Model

Key Takeaway

Check Your Understanding

You've seen what reflection is, how to use it, and the real tools that depend on it every day. Let's check your understanding.

You now understand how a huge share of the .NET ecosystem's "it just works with any type" tooling is actually built — and exactly why that flexibility has a real performance price. Next up: attributes, the declarative metadata reflection so often reads back.

dotnetmadeeasy.com — Learn C# and .NET, the right way.