¿Cómo obtengo el miembro al que se aplicó mi atributo personalizado?

Dado que parece haber mucha confusión con respecto a cómo funcionan los marcos de pila y los métodos, aquí hay una demostración simple:

static void Main(string[] args)
{
    MyClass c = new MyClass();
    c.Name = "MyTest";
    Console.ReadLine();
}

class MyClass
{
    private string name;

    void TestMethod()
    {
        StackTrace st = new StackTrace();
        StackFrame currentFrame = st.GetFrame(1);
        MethodBase method = currentFrame.GetMethod();
        Console.WriteLine(method.Name);
    }

    public string Name
    {
        get { return name; }
        set
        {
            TestMethod();
            name = value;
        }
    }
}

La salida de este programa será:

Set_Name

Las propiedades en C# son una forma de azúcar sintáctico. Compilan los métodos getter y setter en el IL, y es posible que algunos lenguajes. NET ni siquiera los reconozcan como propiedades-la resolución de propiedades se hace completamente por convención, no hay realmente cualquier regla en el IL spec.

Ahora, digamos por el momento que tienes una muy buena razón para que un programa quiera examinar su propia pila (y hay muy pocas razones prácticas para hacerlo). ¿Por qué en el mundo querría que se comportara de manera diferente para las propiedades y los métodos?

La razón detrás de los atributos es que son una especie de metadatos. Si desea un comportamiento diferente, codifíquelo en el atributo. Si un atributo puede significar dos cosas diferentes dependiendo de si se aplica a un método o propiedad, entonces usted debe tener dos atributos. Establecer el objetivo en el primero a AttributeTargets.Method y el segundo a AttributeTargets.Property. Simple.

Pero una vez más, caminar por su propia pila para recoger algunos atributos del método de llamada es peligroso en el mejor de los casos. En cierto modo, está congelando el diseño de su programa, lo que hace que sea mucho más difícil para cualquier persona extender o refactorizar. Esta no es la forma en que los atributos se usan normalmente. A más ejemplo apropiado, sería algo así como un atributo de validación:

public class Customer
{
    [Required]
    public string Name { get; set; }
}

Entonces su código validador, que no sabe nada sobre la entidad real que se está pasando, puede hacer esto:

public void Validate(object o)
{
    Type t = o.GetType();
    foreach (var prop in
        t.GetProperties(BindingFlags.Instance | BindingFlags.Public))
    {
        if (Attribute.IsDefined(prop, typeof(RequiredAttribute)))
        {
            object value = prop.GetValue(o, null);
            if (value == null)
                throw new RequiredFieldException(prop.Name);
        }
    }
}

En otras palabras, estás examinando los atributos de una instancia que te fue dada pero que no necesariamente sabes nada sobre el tipo de. Atributos XML, atributos de contrato de datos, incluso atributos de atributos: casi todos los atributos en. NET Framework son utilizado de esta manera, para implementar alguna funcionalidad que es dinámica con respecto al tipo de una instancia pero no con respecto al estado del programa o lo que pasa a estar en la pila. Es muy poco probable que realmente esté en control de esto en el punto donde crea el seguimiento de la pila.

Así que voy a recomendar de nuevo que no use el enfoque de caminar sobre la pila a menos que tenga una muy buena razón para hacerlo que no nos haya dicho ya casi. De lo contrario, es probable que se encuentre en un mundo de dolor.

Si es absolutamente necesario (no diga que no le advertimos), use dos atributos, uno que se puede aplicar a los métodos y otro que se puede aplicar a las propiedades. Creo que encontrarás que es mucho más fácil trabajar con eso que con un solo súper atributo.