How is it possible that C# attributes have "Attribute" in their name (e.g. DataMemberAttribute
) but are initialized without this suffix? e.g.:
[DataMember]
private int i;
How is it possible that C# attributes have "Attribute" in their name (e.g. DataMemberAttribute
) but are initialized without this suffix? e.g.:
[DataMember]
private int i;
this is the same thing. [XAttribute] == [X]
from MSDN:
By convention, all attribute names end with the word "Attribute" to distinguish them from other items in the .NET Framework. However, you do not need to specify the attribute suffix when using attributes in code. For example,
[DllImport]
is equivalent to[DllImportAttribute]
, butDllImportAttribute
is the attribute's actual name in the .NET Framework.
we can read also:
If an attribute class is found both with and without this suffix, an ambiguity is present, and a compile-time error results. If the attribute-name is spelled such that its right-most identifier is a verbatim identifier, then only an attribute without a suffix is matched, thus enabling such an ambiguity to be resolved:
using System;
[AttributeUsage(AttributeTargets.All)]
public class X: Attribute
{}
[AttributeUsage(AttributeTargets.All)]
public class XAttribute: Attribute
{}
[X] // Error: ambiguity
class Class1 {}
[XAttribute] // Refers to XAttribute
class Class2 {}
[@X] // Refers to X
class Class3 {}
[@XAttribute] // Refers to XAttribute
class Class4 {}
According to the C# Language Specification,
By convention, attribute classes are named with a suffix of
Attribute
. An attribute-name of the form type-name may either include or omit this suffix.
This is a shortcut provided by the C# compiler and by no means a CLR feature. Another example of special treatment of attributes by the compiler is an ObsoleteAttribute attribute: this one forces a compiler to issue a warning/error, but it has no special meaning for the CLR.
As for how attributes are resolved, see the link above. To sum it up:
If an attribute class is found both with and without this suffix, an ambiguity is present, and a compile-time error results. If the
attribute-name
is spelled such that its right-most identifier is a verbatim identifier, then only an attribute without a suffix is matched, thus enabling such an ambiguity to be resolved.
A "verbatim identifier" is an identifier with an @
prefix.
Continuing with MSDN:
using System;
[AttributeUsage(AttributeTargets.All)]
public class X: Attribute
{}
[AttributeUsage(AttributeTargets.All)]
public class XAttribute: Attribute
{}
[X] // Error: ambiguity
class Class1 {}
[XAttribute] // Refers to XAttribute
class Class2 {}
[@X] // Refers to X
class Class3 {}
[@XAttribute] // Refers to XAttribute
class Class4 {}
The attribute
[X]
is ambiguous, since it could refer to eitherX
orXAttribute
. Using a verbatim identifier allows the exact intent to be specified in such rare cases. The attribute[XAttribute]
is not ambiguous (although it would be if there was an attribute class namedXAttributeAttribute
!). If the declaration for classX
is removed, then both attributes refer to the attribute class namedXAttribute
, as follows:
using System;
[AttributeUsage(AttributeTargets.All)]
public class XAttribute: Attribute
{}
[X] // Refers to XAttribute
class Class1 {}
[XAttribute] // Refers to XAttribute
class Class2 {}
[@X] // Error: no attribute named "X"
class Class3 {}
It's a convention in the C#-compiler. Like it says on the MSDN-page on 'Using Attributes':
By convention, all attribute names end with the word "Attribute" to distinguish them from other items in the .NET Framework. However, you do not need to specify the attribute suffix when using attributes in code. For example, [DllImport] is equivalent to [DllImportAttribute], but DllImportAttribute is the attribute's actual name in the .NET Framework.
It works the same way in VB.NET.