3

Suppose that I have a simple custom attribute:

public class MyCustomAttribute : Attribute
{
    public MyCustomAttribute(string parameter1)
    {
    }
}

And use it to decorate a member in a class

public class Foo
{
    [MyCustomAttribute("test")]
    string bar;
}

When the constructor for MyCustomAttribute runs - in this example with "test" as the value of the first parameter - is it possible to get any of the metadata regarding the member that was decorated? i.e. in this example is it possible to know that the property is called 'bar' or that it is of type System.String?

I can't see how to do it - maybe I am going blind! - but it seems like that metadata should be available somewhere?

noelep
  • 55
  • 4
  • I've wondered this myself but never seen anything. I'm hoping someone makes me look stupid by giving some way of how, but the impression I get is that attributes are meant to understand members during reflection, as compared to discovering members (as you'd be doing in this constructor) in order to reflect. – Matthew Haugen Sep 10 '14 at 02:02
  • 2
    Not that I am aware of. Attributes are generally observed from outside of their own scope. They are markers for other code to check. That is, you look _at_ them.. and they look at their own feet. – Simon Whitehead Sep 10 '14 at 02:02
  • +1 to @SimonWhitehead, attributes are a way to add metadata about a specific class/member. They do not hold any information about what they have been applied to. You can almost treat them as a compile time constant, that happens to be related to a class or member. – Xenolightning Sep 10 '14 at 02:11
  • Yes, I absolutely agree it is a bit...backwards. Right now I am using them in the traditional way (reflection) but need to specifically access the Name from the PropertyInfo. I was wondering if there was a way to encapsulate that step in the attribute itself. – noelep Sep 10 '14 at 02:15
  • @noelep What do you need to use the name of the Property in the Attribute for? This sounds really muddled, and as though there should be a separate class that interprets attributes and does the required logic. – Xenolightning Sep 10 '14 at 02:20
  • Attribute classes are very limited because they need to be completely processed at compile time, otherwise the C# compiler would become a recursive nightmare. To do the kind of thing you're talking about I've written a C# preprocessor that works together with some "fake attributes". I once wrote an SO answer that outlines the ideas involved: http://stackoverflow.com/questions/18119857/how-to-refer-to-an-identifier-without-writing-it-into-a-string-literal-in-c/18158212#18158212 – RenniePet Sep 10 '14 at 05:46
  • @Xenolightning I agree - a class that walks the members and combines the Attribute information with the reflected metadata is what I have right now. At this stage it is as much trying to understand why that metadata isn't available in the Attribute constructor. Would love to hear the underlying reasons - is it a fundamental limitation of how the compiler works - or explicitly not made available because it is the wrong thing to do. I guess I could go take a look at the Roslyn source...! – noelep Sep 10 '14 at 13:20

1 Answers1

0

No.

Of course you could add additional parameters to the attribute constructor to provide any information you like, but there is nothing like that available out of the box.

yoyo
  • 8,310
  • 4
  • 56
  • 50