CODEWITHSUNDEEP
c#.netvb.netattributes
Saeed mohammadi
Saeed mohammadi

Reputation: 309

What "Attributes" really are?

I've already read a lot about attributes and I know rather much about them.

But one thing that I can't understand is : "What they really are?".

I mean if this isn't inheritance or interface implementation or other OOP understandable concepts so what concept is this?

what happens behind the scene when you use and attribute for a class or a class member?

I have read other related posts in this site. But they don't give much information about what really happens. They are more about usage of attributes. And an incomprehensibility explanation of what they really are.In the other post this is what declares them : "Metadata. Data about your objects/methods/properties." which doesn't clarify concepts

Upvotes: 1

Views: 171

Answers (2)

Erik Funkenbusch
Erik Funkenbusch

Reputation: 93424

Attributes are a very simple concept, but they are complicated by the fact that so many parts of the framework use them in ways that seem like magic.

Attributes are nothing more than Metadata. That is, they are essentially comments that the framework can read at runtime that describe things about the type. There are all kinds of attributes that are for various purposes, and there is various code written that looks for these attributes.

Attributes by themselves don't do anything. They need some other code to read them, and then do something based on what they find.

Attribute classes can be instantiated, and then code in them can be executed, but again, only if some other code requests it. Much of this code is often hidden by frameworks. For instance, in MVC there are attributes used for declaring methods to be Post or Get methods... or that a method must be authenticated before it can be called... These attributes are only useful because the MVC framework has code to check for them, and take action based on them.

In short, an attribute does nothing by itself. It only functions in conjunction with other code (usually in the framework) that makes use of it. As such, attributes can be almost anything that anyone can dream up.

Upvotes: 1

Marc Gravell
Marc Gravell

Reputation: 1062560

They are simply metadata stored in the underlying definition (not instance) of the type. For example, if I do:

[Description("some text")]
public string Name {get;set;}

then the fact that DescriptionAttribute with a description constructor-parameter of "some text" is stored in the IL against the property Name. This has no impact on the cost of each instance, and it does nothing by itself. The only time this data is used is if code explicitly asks the runtime something like:

  • "what additional attribute metadata do you have against Name ?"
  • "does Name have a DescriptionAttribute ?"
  • "please construct me the DescriptionAttribute stored against Name, if one"

and then does something with the result.

CAVEAT: there are some attributes that are processed differently by the compiler and/or CLI, and are implemented differently. [Serializable], for example, becomes an IL type flag - not an IL attribute - but the runtime shims it so that the APIs report it as though it were the other.

Upvotes: 2

Related Questions