Expression Trees

By the end of this lesson you'll be able to treat a piece of C# logic as data you can read, build, and rewrite at runtime — then compile it back into runnable code. This is the machinery behind LINQ providers and ORMs like Entity Framework, which read your queries and translate them into SQL.

1. Expression<Func> vs a Plain Func

Write (a, b) => a + b and what you get depends on the type you store it in. Store it in a Func<int, int, int> and the compiler turns it into IL — runnable machine code you can call but never look inside. Store the identical lambda in an Expression<Func<int, int, int>> and the compiler instead builds a tree of objects describing the code: a Lambda node, with a parameter list and an Add node inside it. The tree is data, so you can read it, take it apart, and only later compile it into a delegate. Read this worked example, run it, then you'll write your own.

using System;
using System.Linq.Expressions;        // 👈 needed for Expression<T> and the factory methods

class Program
{
    static void Main()
    {
        // A lambda stored as a DELEGATE is compiled IL — runnable code.
        // You can CALL it, but you can't look inside it.
        Func<int, int, int> addFunc = (a, b) => a + b;
        Console.WriteLine($"Func result: {addFunc(3, 5)}");   // Func result: 8

        // The SAME lambda stored as an EXPRESSION is a data structure (a tree).
...

Your turn. The program below is almost complete — store a lambda as an expression tree, then compile it so you can call it. Fill in the two blanks marked ___ using the hints, then run it.

using System;
using System.Linq.Expressions;

class Program
{
    static void Main()
    {
        // 🎯 YOUR TURN — fill in the blanks marked with ___, then run it.

        // 1) Store the lambda  (a, b) => a + b  as an EXPRESSION TREE,
        //    NOT as a Func. The type on the left already says Expression<...>.
        Expression<Func<int, int, int>> addExpr = ___;   // 👉 (a, b) => a + b

        // 2) Turn the tree into a runnable delegate.
        //    An expression is DATA — you must 
...

2. Building a Tree by Hand

The compiler builds a tree for you from a lambda, but you can also assemble one node by node with the Expression factory methods — that's how dynamic code does it when the logic isn't known until runtime. The pattern is always the same: make the parameter nodes with Expression.Parameter, combine them into a body (Expression.Add, Expression.Subtract, Expression.Multiply, …), then wrap the body and its parameters in an Expression.Lambda<T>. Compile, and you have a delegate. Now you try: build (x, y) => x - y by hand.

using System;
using System.Linq.Expressions;

class Program
{
    static void Main()
    {
        // 🎯 YOUR TURN — build the expression  (x, y) => x - y  by hand.
        // Fill in the blanks, then run it.

        // 1) Two parameter nodes named "x" and "y", both of type int.
        ParameterExpression x = Expression.Parameter(typeof(int), "x");
        ParameterExpression y = Expression.Parameter(typeof(___), "y");  // 👉 the type:  int

        // 2) A subtraction node:  x - y
        // 
...

3. Why LINQ Providers & ORMs Need Trees

This is the reason expression trees exist. When you write dbContext.Products.Where(p => p.Price > 100), Entity Framework Core doesn't run that lambda in C#. It can't — the data is in a database. Instead, Where on an IQueryable<T> takes an Expression, so EF receives the tree, walks it, and translates p.Price > 100 into WHERE [Price] > 100 SQL. A plain Func would be a sealed black box it could only run in memory — meaning it would download every row first. The tree is glass: the provider can see through it.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;

class Product
{
    public string Name { get; set; } = "";
    public decimal Price { get; set; }
}

class Program
{
    static void Main()
    {
        var products = new List<Product>
        {
            new() { Name = "Laptop",   Price = 999m },
            new() { Name = "Mouse",    Price = 25m  },
            new() { Name = "Keyboard", Price = 75m  },
            new() { Name = "Monitor",  
...

4. Inspecting & Rewriting with ExpressionVisitor

Once you have a tree you'll often want to walk it — to inspect it, optimise it, or rewrite parts of it. ExpressionVisitor is the built-in walker: subclass it and override a Visit* method (like VisitBinary for +, -, > nodes) to intercept and replace nodes. Trees are immutable — you never edit one in place, you return a new tree. This example swaps every addition for a multiplication, then inspects a node's parts directly.

using System;
using System.Linq.Expressions;

// An ExpressionVisitor walks a tree node by node. Override a Visit method
// to inspect or REPLACE nodes — here, swap every + for a *.
class AddToMultiplyVisitor : ExpressionVisitor
{
    protected override Expression VisitBinary(BinaryExpression node)
    {
        if (node.NodeType == ExpressionType.Add)
            return Expression.Multiply(Visit(node.Left), Visit(node.Right));
        return base.VisitBinary(node);   // leave other operators un
...

// ❌ Recompiles the SAME tree on every iteration — wasteful.
foreach (var n in items)
    use(expr.Compile()(n));

// ✅ Compile ONCE, reuse the delegate.
var fn = expr.Compile();
foreach (var n in items)
    use(fn(n));

using System;
using System.Linq.Expressions;

class Program
{
    static void Main()
    {
        // 🎯 MINI-CHALLENGE: a compiled predicate
        // 1. Declare  Expression<Func<int, bool>> isBig = n => n > 10;
        //    (a predicate is just an expression that returns a bool).
        // 2. Compile it into a Func<int, bool> with .Compile().
        // 3. Test it on 5, 10 and 11 and print each result, e.g.
        //       Console.WriteLine($"5  -> {check(5)}");
        // 4. BONUS: print 
...