The workaround I'm using now, which I will call the "spam approach", is ugly but functional in a limited set of scripts:
public class ReflectionHelper<T> { public MethodInfo GetMethod<TA1>(Expression<Func<T, Func<TA1>>> expr) { return ((MethodCallExpression)expr.Body).Method; } public MethodInfo GetMethod<TA1, TA2>(Expression<Func<T, Action<TA1, TA2>>> expr) { return ((MethodCallExpression)expr.Body).Method; } public MethodInfo GetMethod<TA1, TA2, TA3>(Expression<Func<T, Action<TA1, TA2, TA3>>> expr) { return ((MethodCallExpression)expr.Body).Method; } . . . // And more }
And it goes on to indicate a long list of potential actions and Funcs with various arguments. This allows me to use it like:
(new ReflectionHelper<MyClass>()).GetMethod<string>(mc => mc.SaySomething).Invoke("Hi");
So this is close-ish - I get just a method call by name, and I don't avoid passing fake arguments to do this, but I still realized what the types of its arguments are - more complicated than I had hoped. In a situation with multiple method overloads with the same name, passing argument types, however, limits the list of methods to one specific overload.
Anyway, I would be interested in something even simpler that the method can just take, as in my Question. This would be undefined in method overload situations, but is also the standard .GetMethod (string).
source share