Is there a particular reason LinqKit's expander can't pick up Expressions from fields?

Question

I'm using LinqKit library which allows combining expressions on the fly.

This is a pure bliss for writing Entity Framewok data acess layer because several expressions can optionally be reused and combined, which allows both for readable and efficient code.

Consider following piece of code:

private static readonly Expression<Func<Message, int, MessageView>> _selectMessageViewExpr =     ( Message msg, int requestingUserId ) =>         new MessageView         {             MessageID = msg.ID,             RequestingUserID = requestingUserId,             Body = ( msg.RootMessage == null ) ? msg.Body : msg.RootMessage.Body,             Title = ( ( msg.RootMessage == null ) ? msg.Title : msg.RootMessage.Title ) ?? string.Empty         }; 

We declare an expression that projects Message onto MessageView (I removed the details for clarity).

Now, the data access code can use this expression to get individual message:

var query = CompiledQueryCache.Instance.GetCompiledQuery(     "GetMessageView",     () => CompiledQuery.Compile(         _getMessagesExpr             .Select( msg => _selectMessageViewExpr.Invoke( msg, userId ) ) // re-use the expression             .FirstOrDefault( ( MessageView mv, int id ) => mv.MessageID == id )             .Expand()         )     ); 

This is beautiful because the very same expression can be reused for getting a message list as well:

var query = CompiledQueryCache.Instance.GetCompiledQuery(     "GetMessageViewList",     () => CompiledQuery.Compile(         BuildFolderExpr( folder )             .Select( msg => _selectMessageViewExpr.Invoke( msg, userId ) )             .OrderBy( mv => mv.DateCreated, SortDirection.Descending )             .Paging()             .Expand()         ),     folder     ); 

As you can see, projection expression is stored in _selectMessageViewExpr and is used for building several different queries.

However, I spent a lot of time tracing a strange error where this code crashed at Expand() call.
The error said:

Unable to cast object of type System.Linq.Expressions.FieldExpression to type System.Linq.Expressions.LambdaExpression.

It's only after a while that I realized that everything works when expression is referenced in a local variable before being called Invoke on:

var selector = _selectMessageViewExpr; // reference the field  var query = CompiledQueryCache.Instance.GetCompiledQuery(     "GetMessageView",     () => CompiledQuery.Compile(         _getMessagesExpr             .Select( msg => selector.Invoke( msg, userId ) ) // use the variable             .FirstOrDefault( ( MessageView mv, int id ) => mv.MessageID == id )             .Expand()         )     ); 

This code works as expected.

My question is:

Is there any specific reason why LinqKit doesn't recognize Invoke on expressions stored in fields? Is it just an omission by developer, or is there some important reason why expressions need to be stored in local variables first?

This question can probably be answered by looking at generated code and checking LinqKit sources, however I thought maybe someone related to LinqKit development could answer this question.

Thanks.

Answer 1

I downloaded sourcecode and tried to analyse it. ExpressionExpander does not allow to reference expressions that are stored in variables other than constant. It expects expression that Invoke method is being called upon to reference to object represented by ConstantExpression, not another MemberExpression.

So we cannot provide our reusable expression as reference to any member of the class (even public fields, not properties). Nesting member access (like object.member1.member2 ... etc) is not supported too.

But this can be fixed by traversing initial expression and recusrsively extracting subfields values.

I have replaced TransformExpr method code of ExpressionExpander class to

var lambda = Expression.Lambda(input); object value = lambda.Compile().DynamicInvoke();  if (value is Expression)     return Visit((Expression)value); else     return input; 

and it works now.

In this solution everything I mentioned before (recursively traversing tree) is done for us by ExpressionTree compiler :)