.NET has evolved over the years, but one of the constants has been the use of delegates. For those that don't know what delegates are, they are simply method pointers. Now although not directly related to this article's content, I think it is a good idea to show you a bit about the evolution of delegates leading to lambdas in order for you to understand the rest of the article.

Now it used to be that you had to manually create delegates such as this:

Luckily over the years, Microsoft has given us anonymous delegates which allow us to do things like this:

this.Loaded += delegate
{
MessageBox.Show("in the delegate");
};

Where the signature of this delegate would be something like the following if we had to actually declare it in a non anonymous manner:

internaldelegatevoid MessagDelegate();

Which is all well and good, but sometimes you want the ability to create an anonymous delegate that takes a parameter, or maybe even returns a value. Luckily we can still do this using an anonymous delegate, but we must make sure that the delegate type is known at runtime, so we have to provide a non anonymous delegate signature to use within any method that accepts an anonymous delegate. This allows us to get the correct return type/value.

Now a little bit of time goes by and Microsoft introduced the lambda syntax. There are many great articles on lambdas. I will just show one small example comparing them to anonymous delegates, but you will find more on the internet, have a look.

Using the last example, we could simply replace the delegate(string s) {...} with a lambda, which would be (s) => {...}. Here is a reworked example using the lambda syntax:

But we can actually go one step further and remove the reliance on the UpperCaseAStringDelegate altogether. We can simply replace it with one of the generic Func<T,TResult> delegates where we would then end up with the following code:

Isn't that nicer. That's all I wanted to say in this section, I just wanted you to understand what the Func<T,TResult> delegates and lambdas are actually doing before we move on to some of the more finer details of the Creating Expressions and the Expression namespace.

Now that we know about lambdas and some of the Func<T,TResult> delegates, let's proceed to look at Expressions. Expressions came with lambdas. Microsoft has this to say about Expression Trees "Expression trees represent language-level code in the form of data. The data is stored in a tree-shaped structure. Each node in the expression tree represents an expression, for example a method call or a binary operation such as x < y."

So what does that mean to us. Well let's consider the following diagram, where we have one of the generic Func<T,T,TResult> delegates, which means we have a lambda that takes 2 parameters and returns a value. The following illustration shows an example of an expression and its representation in the form of an expression tree.

So you can see from this that we have things like BinaryExpression/ParameterExpression/MemberExpression. Ok, fine. But what would a concrete example look like.

I think the best way to do this is for me to show you some examples. I will show you two examples, all based on the following test data:

Example 1

This simply uses a lambda within a Where extension method. But could we do this differently, well yeah we could also do the following, where we actually have an Expression<Func<String, Boolean>> variable, which we MUST compile when it is used in the where extension method. Do you see where all this is going?

So a little explanation here, as we are using an object and want to use one of its methods, we need to use a MemberExpression, and as we need to test this against a constant, we need to use a ConstantExpression. We also need to test for equality, so we need to use a BinaryExpression. Finally we need to create an overall Expression Tree, which we can do using the Expression.Lambda<Func<T,TResult>>. If you look at the Expression.Lambda method, it may begin to make a bit more sense:

Example 3

The last example will be trying to do the following (x) => x.Length > 1 where x is a String:

This is much the same as the last example, with the exception that I am building the entire tree using the following Expression.Lambda() method, where I am effectively building the entire Expression Tree in 1 hit.

Visual Studio comes with an Expression Visualiser or the SDK has it, what I would do is write the LINQ query as from x in whatever where x.Contains("dghdsgh") and then see what Expression that creates.

See what I mean

Sacha Barber

Microsoft Visual C# MVP 2008/2009

Codeproject MVP 2008/2009

Your best friend is you.
I'm my best friend too. We share the same views, and hardly ever argue

An article was written recently about supporting the IQueryable and IQueryProvider interfaces and while that article was great, I realized that I needed more information on Expression trees before it would really make sense. This was perfect. Thanks!

I see that several people are wondering what one could do by generating lambda expressions at runtime.

I wondered about this too. And one idea that was suggested to me was that of a higher function (a function that return another function). The possibilities of that kind of function are greatly enhanced with dynamic lambda expressions.