¿Cómo uso la reflexión para invocar un método privado?

Hay un grupo de métodos privados en mi clase, y necesito llamar a uno dinámicamente en función de un valor de entrada. Tanto el código de invocación como los métodos de destino están en la misma instancia. El código se ve así:

MethodInfo dynMethod = this.GetType().GetMethod("Draw_" + itemType);
dynMethod.Invoke(this, new object[] { methodParams });

En este caso, GetMethod()no devolverá métodos privados. ¿ BindingFlagsQué necesito suministrar para GetMethod()que pueda localizar métodos privados?

Simplemente cambie su código para usar la versiónGetMethod sobrecargada que acepta BindingFlags:

MethodInfo dynMethod = this.GetType().GetMethod("Draw_" + itemType, 
    BindingFlags.NonPublic | BindingFlags.Instance);
dynMethod.Invoke(this, new object[] { methodParams });

Aquí está la documentación de enumeración de BindingFlags .

BindingFlags.NonPublicno devolverá ningún resultado por sí solo. Resulta que combinarlo con BindingFlags.Instancehace el truco.

MethodInfo dynMethod = this.GetType().GetMethod("Draw_" + itemType, 
    BindingFlags.NonPublic | BindingFlags.Instance);

Y si realmente quieres meterte en problemas, haz que sea más fácil de ejecutar escribiendo un método de extensión:

static class AccessExtensions
{
    public static object call(this object o, string methodName, params object[] args)
    {
        var mi = o.GetType ().GetMethod (methodName, System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance );
        if (mi != null) {
            return mi.Invoke (o, args);
        }
        return null;
    }
}

Y uso:

    class Counter
    {
        public int count { get; private set; }
        void incr(int value) { count += value; }
    }

    [Test]
    public void making_questionable_life_choices()
    {
        Counter c = new Counter ();
        c.call ("incr", 2);             // "incr" is private !
        c.call ("incr", 3);
        Assert.AreEqual (5, c.count);
    }

Microsoft modificó recientemente la API de reflexión haciendo que la mayoría de estas respuestas sean obsoletas. Lo siguiente debería funcionar en plataformas modernas (incluidos Xamarin.Forms y UWP):

obj.GetType().GetTypeInfo().GetDeclaredMethod("MethodName").Invoke(obj, yourArgsHere);

O como un método de extensión:

public static object InvokeMethod<T>(this T obj, string methodName, params object[] args)
{
    var type = typeof(T);
    var method = type.GetTypeInfo().GetDeclaredMethod(methodName);
    return method.Invoke(obj, args);
}

Nota:

• Si el método deseado está en una superclase de objla Tgenérico se debe establecer explícitamente al tipo de la superclase.

• Si el método es asíncrono, puede usarlo await (Task) obj.InvokeMethod(…).

¿Estás absolutamente seguro de que esto no se puede hacer a través de la herencia? La reflexión es lo último que debe tener en cuenta al resolver un problema, dificulta la refactorización, la comprensión de su código y cualquier análisis automatizado.

Parece que solo debería tener una clase DrawItem1, DrawItem2, etc. que anule su dynMethod.

La reflexión especialmente sobre los miembros privados es incorrecta

• Reflexión rompe tipo seguridad. Puede intentar invocar un método que ya no existe (o con los parámetros incorrectos, o con demasiados parámetros, o no lo suficiente ... o incluso en el orden incorrecto (este es mi favorito :)). Por cierto, el tipo de retorno también podría cambiar.
• La reflexión es lenta.

La reflexión de miembros privados rompe el principio de encapsulación y, por lo tanto, expone su código a lo siguiente:

• Aumente la complejidad de su código porque tiene que manejar el comportamiento interno de las clases. Lo que está oculto debe permanecer oculto.
• Hace que su código sea fácil de romper ya que se compilará pero no se ejecutará si el método cambió su nombre.
• Hace que el código privado sea fácil de descifrar porque si es privado no está destinado a llamarse de esa manera. Tal vez el método privado espera algún estado interno antes de ser llamado.

¿Qué pasa si debo hacerlo de todos modos?

Hay casos en los que, cuando depende de un tercero o necesita alguna API no expuesta, debe reflexionar. Algunos también lo usan para probar algunas clases que poseen pero que no quieren cambiar la interfaz para dar acceso a los miembros internos solo para las pruebas.

Si lo haces, hazlo bien

• Mitigar lo fácil de romper:

Para mitigar el problema fácil de romper, lo mejor es detectar cualquier ruptura potencial probando en pruebas unitarias que se ejecutarían en una compilación de integración continua o similar. Por supuesto, significa que siempre usa el mismo ensamblado (que contiene los miembros privados). Si usa una carga dinámica y una reflexión, le gusta jugar con fuego, pero siempre puede detectar la Excepción que puede producir la llamada.

• Mitigar la lentitud de la reflexión:

En las versiones recientes de .Net Framework, CreateDelegate supera en un factor 50 la invocación MethodInfo:

// The following should be done once since this does some reflection
var method = this.GetType().GetMethod("Draw_" + itemType, 
  BindingFlags.NonPublic | BindingFlags.Instance);

// Here we create a Func that targets the instance of type which has the 
// Draw_ItemType method
var draw = (Func<TInput, Output[]>)_method.CreateDelegate(
                 typeof(Func<TInput, TOutput[]>), this);

drawlas llamadas serán aproximadamente 50 veces más rápidas que el MethodInfo.Invoke uso drawcomo un estándar Funccomo ese:

var res = draw(methodParams);

Consulte esta publicación mía para ver el punto de referencia sobre invocaciones de diferentes métodos

¿No podría simplemente tener un método de dibujo diferente para cada tipo que desea dibujar? Luego llame al método Draw sobrecargado pasando el objeto de tipo itemType para dibujar.

Su pregunta no deja en claro si itemType realmente se refiere a objetos de diferentes tipos.

Creo que se puede pasar que BindingFlags.NonPubliccuando se es el GetMethodmétodo.

Invoca cualquier método a pesar de su nivel de protección en la instancia del objeto. ¡Disfrutar!

public static object InvokeMethod(object obj, string methodName, params object[] methodParams)
{
    var methodParamTypes = methodParams?.Select(p => p.GetType()).ToArray() ?? new Type[] { };
    var bindingFlags = BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance | BindingFlags.Static;
    MethodInfo method = null;
    var type = obj.GetType();
    while (method == null && type != null)
    {
        method = type.GetMethod(methodName, bindingFlags, Type.DefaultBinder, methodParamTypes, null);
        type = type.BaseType;
    }

    return method?.Invoke(obj, methodParams);
}

Lea esta respuesta (complementaria) (que a veces es la respuesta) para comprender a dónde va esto y por qué algunas personas en este hilo se quejan de que "todavía no funciona"

Escribí exactamente el mismo código que una de las respuestas aquí . Pero aún tenía un problema. Puse un punto de quiebre en

var mi = o.GetType().GetMethod(methodName, BindingFlags.NonPublic | BindingFlags.Instance );

Se ejecutó pero mi == null

Y continuó con este comportamiento hasta que "reconstruí" todos los proyectos involucrados. Estaba probando un ensamblaje mientras el método de reflexión estaba en el tercer ensamblaje. Fue totalmente confuso, pero utilicé la ventana Inmediato para descubrir métodos y descubrí que un método privado que intenté probar en la unidad tenía un nombre antiguo (lo cambié de nombre). Esto me dijo que el antiguo ensamblaje o PDB todavía está disponible, incluso si el proyecto de prueba de unidad se construye, por alguna razón el proyecto que prueba no se construyó. "reconstruir" funcionó

BindingFlags.NonPublic