Mise à jour: Cela marche, j'étais stupide :(problème de paramètres avec Expression.Lambda()
j'ai la méthode d'extension suivante
public static string ExtMethod(this object self, object myparameter);
lors de l'exécution ce que l'on appelle dans un certain nombre des moyens façons, je pense que ce sont toutes les possibilités:
Expression<Func<T, string>> expr = x => x.property.ExtMethod(5);
Expression<Func<T, string>> expr = x => x.property.ExtMethod(new object());
Expression<Func<T, string>> expr = x => x.property.ExtMethod(someMethod());
Expression<Func<T, string>> expr = x => x.property.ExtMethod(x.someMethod());
Expression<Func<T, string>> expr = x => x.property.ExtMethod(x.OtherProperty);
ce que je dois faire est d'évaluer la « myparameter
», étant donné "expr
« et un » T
"
à cause des deux cas où x
est utilisé dans myparameter
, je pensais que je devais créer un délégué de la forme:
Expression<Func<T, object>> expr = x => [myparameter expression here]
Je pensais que cela fonctionnerait:
var extMethodExpr = expr.Body as MethodCallExpression;
var myparameterExpr = extMethodExpr.Arguments[1];
var myparam = Expression.Lambda(myparameterExpr, expr.Parameters).Compile().Invoke(someT)
mais pour les expressions qui ne concernent pas x
,
i get
TargetParameterCountException
:(
dans ces cas, si je fais:
var myparam = Expression.Lambda(myparameterExpr).Compile().Invoke(someT)
il fonctionne très bien.
Comment résoudre ce problème?
grâce
C'est hardcore ... Je n'arrive toujours pas à comprendre quel est le problème. :) –
Les méthodes d'extension sur objet sont rarement une bonne idée; et (pedant) vous créez un arbre d'expression (pas un délégué) - mais en regardant maintenant ... –
@Marc c'est juste pseudo code;) –