You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expression trees are generated for projectable methods as part of an external class. A projectable expression is simply a rewrite of the original implementation. If this refers to a private member then that is not accessible from the external class. There are 2 workarounds possible:
We generate expressions as part of a partial class. e.g., when you declare the container class of your projectables as Partial, we can generate the projectable methods within the same class and hence those generated projectable methods will have access to the internals of that class.
We rewrite the generated expression to basically inline the logic of the internal member that it's referring to, e.g.
classFoo{[Projectable]privateintSum(inta,intb)=>a+b;[Projectable]publicintSumAll(int[]numbers)=>numbers.Aggregate((next,total)=>Sum(total,next),0);}// Generated code:classGenerated_SumAll{// BeforepublicExpression<Func<int[],int>>Expression=(int[]numbers)=>numbers.Aggregate((next,total)=>Foo.Sum(total,next),0)// After
public Expression<Func<int[],int>>Expression=(int[]numbers)=>numbers.Aggregate((next,total)=>total+next,0);}
The downside of the second approach is that it would not be able to generate code for projectables that are part of a type that lives in a different assembly as it would not have access to the syntax tree for that method.
Either way, this could be implemented. Happy to accept a PR here.
Is supporting the use of protected/private methods/members in a projected expression something that can be added?
The text was updated successfully, but these errors were encountered: