Attribute

[Tony Johansson]

Hello!

Here I have a simple example of a custom defined Attribute class called
CodeStatus.
Now to my question when I debug this application and I set a breakpoint in
the CodeStatus attribute class
I will never enter that code. So what is the point in using attribute when
the Attribute class is never executed.

I have probably misunderstood something here about Attribute.

So when is the attribute class CodeStatus called ?
Why is it not possible to set a breakpoint that will be hit when the
Attribute class is executed.


using System;

public class CodeStatus : System.Attribute
{
private string STATUS;
private string TESTER;
private string CODER;

public CodeStatus(string Status)
{
this.STATUS = Status;
}

public string Tester
{
set { TESTER = value; }
get { return TESTER; }
}

public string Coder
{
set { CODER = value; }
get { return CODER; }
}

public override string ToString()
{ return STATUS; }
}

[CodeStatus("Final", Coder="Bills")]
public class Rectangle
{
private int length;
private int height;

public Rectangle(int _length, int _height)
{
length = _length;
height = _height;
}

public int Length
{
set { length = value; }
get { return length; }
}

public int Height
{
set { height = value; }
get { return height; }
}

}

public class myApp
{
static void Main(string[] args)
{
Rectangle rect = new Rectangle(5,7);
}
}

//Tony

 

[Jon Skeet [C# MVP]]

Here I have a simple example of a custom defined Attribute class called
CodeStatus.
Now to my question when I debug this application and I set a breakpoint in
the CodeStatus attribute class
I will never enter that code. So what is the point in using attribute when
the Attribute class is never executed.

The point is to store metadata. If you fetch the attribute on the
Rectangle class, you'll be able to access the properties. I don't know
exactly how attributes are serialized/deserialized, but it shouldn't
really matter - they're not expected to be "smart" in themselves.
They're just a way of decorating elements of your code with metadata.

 

[Tony Johansson]

Hello!

I just want to know when is the custom attibute CodeStatus called ?
Do you mean that it's called in the background in some way that's way I
can't use the debugger.

Even if I can't use the debugger the CodeStatus attribute is loaded with
data from
CodeStatus("Final", Coder="Bills")]

Does it sound correct what I'm saying.

//Tony

 

[Jon Skeet [C# MVP]]

I just want to know when is the custom attibute CodeStatus called ?

What do you mean by "called"? It's a class - classes aren't "called",
methods are called.

Do you mean that it's called in the background in some way that's way I
can't use the debugger.

Even if I can't use the debugger the CodeStatus attribute is loaded with
data from
CodeStatus("Final", Coder="Bills")]

Does it sound correct what I'm saying.

I suspect it's hidden by the magic of how the CLR
serializes/deserializes attributes. I've never tried putting any non-
trivial code in attribute properties.

The may be more in CLR via C#, which I'm reading at the moment... I'll
let you know if I find anything.

 

[Tony Johansson]

Hello!

What I mean is from somewhere is the property and methods for the CodeStatus
called and
I can use reflection to ask for example the Rectangle class about all
attributes that is target that class.

When I do so I can see that the custom attribute class has some data that
was set in some way by this
CodeStatus("Final", Coder="Bills")]
statement.

//Tony

I just want to know when is the custom attibute CodeStatus called ?

What do you mean by "called"? It's a class - classes aren't "called",
methods are called.

Do you mean that it's called in the background in some way that's way I
can't use the debugger.

Even if I can't use the debugger the CodeStatus attribute is loaded with
data from
CodeStatus("Final", Coder="Bills")]

Does it sound correct what I'm saying.

I suspect it's hidden by the magic of how the CLR
serializes/deserializes attributes. I've never tried putting any non-
trivial code in attribute properties.

The may be more in CLR via C#, which I'm reading at the moment... I'll
let you know if I find anything.

--
Jon Skeet - <[email protected]>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

 

[Jon Skeet [C# MVP]]

What I mean is from somewhere is the property and methods for the CodeStatus
called and

I don't know when the setter is called. It's possible it's called at
compile-time somehow, but the serialized form is then deserialized
without calling it again at execution time.

I can use reflection to ask for example the Rectangle class about all
attributes that is target that class.
Yes.

When I do so I can see that the custom attribute class has some data that
was set in some way by this
CodeStatus("Final", Coder="Bills")]
statement.

Indeed. It's possible that putting code in the getter will make it act
in a particular way - I don't know. I'd steer clear of that if I were
you though.

 

[Alun Harford]

It's only instantiated when you query the metadata.

What do you mean by "called"? It's a class - classes aren't "called",
methods are called.

Do you mean that it's called in the background in some way that's way I
can't use the debugger.

Even if I can't use the debugger the CodeStatus attribute is loaded with
data from
CodeStatus("Final", Coder="Bills")]

Does it sound correct what I'm saying.

I suspect it's hidden by the magic of how the CLR
serializes/deserializes attributes. I've never tried putting any non-
trivial code in attribute properties.

The may be more in CLR via C#, which I'm reading at the moment... I'll
let you know if I find anything.

The IL essentially contains a reference to a constructor, the parameters
for that constructor, and a set of key-value pairs to populate the
properties (all of which are baked in). When you call
GetCustomAttributes(...) the CLR will create an instance of the
attribute and then call the setters for each property in turn (and so
every call to GetCustomAttributes will get a different instance).

The only real gotcha is the limitations on the types of the properties
and constructor parameters you can bake into an assembly (Type, string,
char, bool, byte, short, int, long, float, double and any enum based on
a CLS-compliant base integer type).

</IL geek>

Alun Harford