I am trying to create an expression tree that represents the following:
myObject.childObjectCollection.Any(i => i.Name == "name");
Shortened for clarity, I have the following:
//'myObject.childObjectCollection' is represented here by 'propertyExp'
//'i => i.Name == "name"' is represented here by 'predicateExp'
//but I am struggling with the Any() method reference - if I make the parent method
//non-generic Expression.Call() fails but, as per below, if i use <T> the
//MethodInfo object is always null - I can't get a reference to it
private static MethodCallExpression GetAnyExpression<T>(MemberExpression propertyExp, Expression predicateExp)
{
MethodInfo method = typeof(Enumerable).GetMethod("Any", new[]{ typeof(Func<IEnumerable<T>, Boolean>)});
return Expression.Call(propertyExp, method, predicateExp);
}
What am I doing wrong? Anyone have any suggestions?
Barry's answer provides a working solution to the question posed by the original poster. Thanks to both of those individuals for asking and answering.
I found this thread as I was trying to devise a solution to a quite similar problem: programmatically creating an expression tree that includes a call to the Any() method. As an additional constraint, however, the ultimate goal of my solution was to pass such a dynamically-created expression through Linq-to-SQL so that the work of the Any() evaluation is actually performed in the DB itself.
Unfortunately, the solution as discussed so far is not something that Linq-to-SQL can handle.
Operating under the assumption that this might be a pretty popular reason for wanting to build a dynamic expression tree, I decided to augment the thread with my findings.
When I attempted to use the result of Barry's CallAny() as an expression in a Linq-to-SQL Where() clause, I received an InvalidOperationException with the following properties:
After comparing a hard-coded expression tree to the dynamically-created one using CallAny(), I found that the core problem was due to the Compile() of the predicate expression and the attempt to invoke the resulting delegate in the CallAny(). Without digging deep into Linq-to-SQL implementation details, it seemed reasonable to me that Linq-to-SQL wouldn't know what to do with such a structure.
Therefore, after some experimentation, I was able to achieve my desired goal by slightly revising the suggested CallAny() implementation to take a predicateExpression rather than a delegate for the Any() predicate logic.
My revised method is:
Now I will demonstrate its usage with EF. For clarity I should first show the toy domain model & EF context I am using. Basically my model is a simplistic Blogs & Posts domain ... where a blog has multiple posts and each post has a date:
With that domain established, here is my code to ultimately exercise the revised CallAny() and make Linq-to-SQL do the work of evaluating the Any(). My particular example will focus on returning all Blogs which have at least one Post that is newer than a specified cutoff date.
Where BuildExpressionForBlogsWithRecentPosts() is a helper function that uses CallAny() as follows:
NOTE: I found one other seemingly unimportant delta between the hard-coded and dynamically-built expressions. The dynamically-built one has an "extra" convert call in it that the hard-coded version doesn't seem to have (or need?). The conversion is introduced in the CallAny() implementation. Linq-to-SQL seems to be ok with it so I left it in place (although it was unnecessary). I was not entirely certain if this conversion might be needed in some more robust usages than my toy sample.
There are several things wrong with how you're going about it.
You're mixing abstraction levels. The T parameter to
GetAnyExpression<T>
could be different to the type parameter used to instantiatepropertyExp.Type
. The T type parameter is one step closer in the abstraction stack to compile time - unless you're callingGetAnyExpression<T>
via reflection, it will be determined at compile time - but the type embedded in the expression passed aspropertyExp
is determined at runtime. Your passing of the predicate as anExpression
is also an abstraction mixup - which is the next point.The predicate you are passing to
GetAnyExpression
should be a delegate value, not anExpression
of any kind, since you're trying to callEnumerable.Any<T>
. If you were trying to call an expression-tree version ofAny
, then you ought to pass aLambdaExpression
instead, which you would be quoting, and is one of the rare cases where you might be justified in passing a more specific type than Expression, which leads me to my next point.In general, you should pass around
Expression
values. When working with expression trees in general - and this applies across all kinds of compilers, not just LINQ and its friends - you should do so in a way that's agnostic as to the immediate composition of the node tree you're working with. You are presuming that you're callingAny
on aMemberExpression
, but you don't actually need to know that you're dealing with aMemberExpression
, just anExpression
of type some instantiation ofIEnumerable<>
. This is a common mistake for people not familiar with the basics of compiler ASTs. Frans Bouma repeatedly made the same mistake when he first started working with expression trees - thinking in special cases. Think generally. You'll save yourself a lot of hassle in the medium and longer term.And here comes the meat of your problem (though the second and probably first issues would have bit you if you had gotten past it) - you need to find the appropriate generic overload of the Any method, and then instantiate it with the correct type. Reflection doesn't provide you with an easy out here; you need to iterate through and find an appropriate version.
So, breaking it down: you need to find a generic method (
Any
). Here's a utility function that does that:However, it requires the type arguments and the correct argument types. Getting that from your
propertyExp
Expression
isn't entirely trivial, because theExpression
may be of aList<T>
type, or some other type, but we need to find theIEnumerable<T>
instantiation and get its type argument. I've encapsulated that into a couple of functions:So, given any
Type
, we can now pull theIEnumerable<T>
instantiation out of it - and assert if there isn't (exactly) one.With that work out of the way, solving the real problem isn't too difficult. I've renamed your method to CallAny, and changed the parameter types as suggested:
Here's a
Main()
routine which uses all the above code and verifies that it works for a trivial case: