I will keep it really simple,
How do I get expression tree out of lambda??
or from query expression ?
Asked
Active
Viewed 2.8k times
4 Answers
68
You must assign the lambda to a different type:
// Gives you a delegate:
Func<int, int> f = x => x * 2;
// Gives you an expression tree:
Expression<Func<int, int>> g = x => x * 2;
The same goes for method arguments. However, once you've assigned such a lambda expression to a Func<> type, you can't get the expression tree back.
Konrad Rudolph
- 530,221
- 131
- 937
- 1,214
-
3Delegate is a better term than lambda, in the first case. Both are lambda expressions, one implicitly converted to an anonymous delegate, other an expression tree. – nawfal Dec 18 '13 at 15:34
-
@nawfal *`f`* is a delegate. But `x => x * 2` is a lambda expression (as you yourself noted). Your comment implies that I said something different but I really didn’t. – Konrad Rudolph Dec 18 '13 at 15:59
-
1You said the second expression gives you an expression tree. Analogous to that, the first lambda expression should *give you a delegate*, not a *lambda* - which is what your first comment is. Not nitpicking, just mentioning so that it helps someone in future. – nawfal Dec 18 '13 at 16:02
-
@nawfal Ah, I see it now – I didn’t look at the comments before. You’re right, I’ll change it. – Konrad Rudolph Dec 18 '13 at 19:33
-
1@KonradRudolph, thanks for the tip. I want to understand why `x => x * 2` is assignable to both `Func
` and `Expression – KFL Mar 13 '15 at 19:50>`? What's the CLR type of `x => x * 2`? And does that mean `Func ` and `Expression >` derive from the same base type? -
2@KFL, the lambda expression itself is an expression you typed as program code, not necessarily corresponding to a specific type. ``Func`` and ``Expression
>`` don't have to derive from the same base type, just ``int`` and ``float`` don't derive from the same base type when you say ``int x = 42`` and ``float y = 42`` – ohw Nov 11 '15 at 11:23 -
@ohw are you sure about that? I've been told that "every expression always has an unambiguous type." https://stackoverflow.com/questions/47311450/c-sharp-class-as-one-value-in-class-mimic-int-behaviour/47311759#comment81586832_47311759 – Kyle Delaney Nov 21 '17 at 19:09
11
Konrad's reply is exact. You need to assign the lambda expression to Expression<Func<...>> in order for the compiler to generate the expression tree. If you get a lambda as a Func<...>, Action<...> or other delegate type, all you have is a bunch of IL instructions.
If you really need to be able to convert an IL-compiled lambda back into an expression tree, you'd have to decompile it (e.g. do what Lutz Roeder's Reflector tool does). I'd suggest having a look at the Cecil library, which provides advanced IL manipulation support and could save you quite some time.
Pierre Arnaud
- 10,212
- 11
- 77
- 108
8
Just to expand on Konrad's answer, and to correct Pierre, you can still generate an Expression from an IL-compiled lambda, though it's not terribly elegant. Augmenting Konrad's example:
// Gives you a lambda:
Func<int, int> f = x => x * 2;
// Gives you an expression tree:
Expression<Func<int, int>> g = x => f(x);
joniba
- 3,339
- 4
- 35
- 49
-
17This **does not** give you the expression tree of the original lamda, it gives you a **new** expression tree that calls the delegate. Nothing more. – Aidiakapi Apr 16 '13 at 12:11
-
The question is not specific on getting an *equivalent* expression. For in-memory LINQ this provides identical functionality. Of course it could not be parsed properly by any LINQ provider. – joniba Aug 29 '17 at 10:52
0
A runtime alternative is to use this project - https://github.com/kostat/XLinq :
// Gives you a lambda:
Func<int, int> f = x => x * 2;
// Gives you an expression tree:
Expression<Func<int, int>> g = ExpressionTree.Parse(f);
Konstantin Triger
- 1,576
- 14
- 11