Question

When you are building the expression tree at runtime there’s no code
emitted. It’s a way to represent .NET code at runtime…

Ok…

Now lets say I have this code :

    ParameterExpression p = Expression.Parameter (typeof (string), "s");
    MemberExpression stringLength = Expression.Property (p, "Length");
    ConstantExpression five = Expression.Constant (5);
    BinaryExpression comparison = Expression.LessThan (stringLength, five);
    Expression<Func<string, bool>> lambda= Expression.Lambda<Func<string, bool>> (comparison, p);

    Func<string, bool> runnable = lambda.Compile();

This code Wont be in IL ? of course it will be ! ( maybe the last line wont emit code until compile …but the first lines I think will emit code !)

So what am i saving here ?

Ok so the first 5 lines did emit code and the last one didn’t… big deal.

What am i missing ? Can you please let me see the whole picture ?

Answer 1

With an Expression Tree, you build a description of some code instead of the code itself.
Expression Trees should not be used in the context of writing regular code that ‘shouldn’t be compiled at compile time’. They should be used in more dynamic scenarios.

The expression tree you show will compile to: s.Length < 5 and you invoke the runnable with bool isStringSmallerThan5 = runnable("MyString").

The whole idea of Expression Trees is that they describe some code and can be compiled at runtime. This means that you can do the following:

BinaryExpression comparison = null;
if (lessThen)
{
    comparison = Expression.LessThan(stringLength, five);
}
else
{
    comparison = Expression.GreaterThan(stringLength, five);
}

Now you can change the behavior of your code at runtime!

The biggest use of Expression Trees is that they can be interpreted by a provider. For example Linq To Entities uses Expression Trees and compiles them to SQL code that can be run against the database. LinqToXml is another example of what you can do with Expression Trees.

This a nice blog post to get you started.