views:

1069

answers:

10
+6  Q: 

Attributes in C#

I know that C# (and .NET in general) is big on attributes. However, despite the fact I have programmed in C# for many years, I haven't found myself ever using them. Would someone get me started on them, and explain where is the best to use them?

Thanks

+2  A: 

Sure. Go serialize a complex object using the XmlSerializer. I'll be here when you come back.

Will
+5  A: 

Attributes get more use in code targeted to other programmers or between distinct parts of a program, rather than code targeted at end users.

For example, you could use attributes to import a dll, indicate how types would interact with visual studio (designer visible, intellisense helps, debugger step-through, etc), how to serialize them, indicate a type is obsolete, describe default values, descriptions, handle COM access, etc.

Those are things that are largely invisible to the end user and that a single programmer could put elsewhere in the source code. But they're useful when only the compiled binary is available and not the source.

Joel Coehoorn
+6  A: 

Most useful attributes in C#

bezieur
although this answer is useful it is not really an answer to the posed question, is it?
Pieter Breed
I don't know: I think it's pretty effective. Knowing what's available is the first step.
Joel Coehoorn
+2  A: 

This question might interest you: Most Useful attributes in C#

Rik
+9  A: 

From Pro C# 2008 and the .NET 3.5 Platform, Fourth Edition by Andrew Troelsen

Understanding Attributed Programming

One role of a .NET compiler is to generate metadata descriptions for all defined and referenced types. In addition to this standard metadata contained within any assembly, the .NET platform provides a way for programmers to embed additional metadata into an assembly using attributes. In a nutshell, attributes are nothing more than code annotations that can be applied to a given type (class, interface, structure, etc.), member (property, method, etc.), assembly, or module. The idea of annotating code using attributes is not new. COM IDL provided numerous predefined attributes that allowed developers to describe the types contained within a given COM server. However, COM attributes were little more than a set of keywords. If a COM developer needed to create a custom attribute, he or she could do so, but it was referenced in code by a 128-bit number (GUID), which was cumbersome at best. Unlike COM IDL attributes (which again were simply keywords), .NET attributes are class types that extend the abstract System.Attribute base class. As you explore the .NET namespaces, you will find many predefined attributes that you are able to make use of in your applications. Furthermore, you are free to build custom attributes to further qualify the behavior of your types by creating a new type deriving from Attribute. Understand that when you apply attributes in your code, the embedded metadata is essentially useless until another piece of software explicitly reflects over the information. If this is not the case, the blurb of metadata embedded within the assembly is ignored and completely harmless.

Attribute Consumers

As you would guess, the .NET 3.5 Framework SDK ships with numerous utilities that are indeed on the lookout for various attributes. The C# compiler (csc.exe) itself has been preprogrammed to discover the presence of various attributes during the compilation cycle. For example, if the C# compiler encounters the [CLSCompliant] attribute, it will automatically check the attributed item to ensure it is exposing only CLS-compliant constructs. By way of another example, if the C# compiler discovers an item attributed with the [Obsolete] attribute, it will display a compiler warning in the Visual Studio 2008 Error List window. In addition to development tools, numerous methods in the .NET base class libraries are preprogrammed to reflect over specific attributes. For example, if you wish to persist the state of an object to file, all you are required to do is annotate your class with the [Serializable] attribute. If the Serialize() method of the BinaryFormatter class encounters this attribute, the object is automatically persisted to file in a compact binary format. The .NET CLR is also on the prowl for the presence of certain attributes. Perhaps the most famous .NET attribute is [WebMethod]. If you wish to expose a method via HTTP requests and automatically encode the method return value as XML, simply apply [WebMethod] to the method and the CLR handles the details. Beyond web service development, attributes are critical to the operation of the .NET security system, Windows Communication Foundation, and COM/.NET interoperability (and so on). Finally, you are free to build applications that are programmed to reflect over your own custom attributes as well as any attribute in the .NET base class libraries. By doing so, you are essentially able to create a set of “keywords” that are understood by a specific set of assemblies.

Applying Attributes in C#

The .NET base class library provides a number of attributes in various namespaces. Below is a snapshot of some—but by absolutely no means all—predefined attributes.

A Tiny Sampling of Predefined Attributes

[CLSCompliant]

Enforces the annotated item to conform to the rules of the Common Language Specification (CLS). Recall that CLS-compliant types are guaranteed to be used seamlessly across all .NET programming languages.

[DllImport]

Allows .NET code to make calls to any unmanaged C- or C++-based code library, including the API of the underlying operating system. Do note that [DllImport] is not used when communicating with COM-based software.

[Obsolete]

Marks a deprecated type or member. If other programmers attempt to use such an item, they will receive a compiler warning describing the error of their ways.

[Serializable]

Marks a class or structure as being “serializable,” meaning it is able to persist its current state into a stream.

[NonSerialized]

Specifies that a given field in a class or structure should not be persisted during the serialization process.

[WebMethod]

Marks a method as being invokable via HTTP requests and instructs the CLR to serialize the method return value as XML.

Building Custom Attributes

The first step in building a custom attribute is to create a new class deriving from System.Attribute. Example:

// A custom attribute.
public sealed class VehicleDescriptionAttribute : System.Attribute
{
    private string msgData;

    public VehicleDescriptionAttribute(string description)
    {
        msgData = description;
    }

    public VehicleDescriptionAttribute() { }

    public string Description
    {
        get { return msgData; }
        set { msgData = value; }
    }
}

As you can see, VehicleDescriptionAttribute maintains a private internal string (msgData) that can be set using a custom constructor and manipulated using a type property (Description). Beyond the fact that this class derived from System.Attribute, there is nothing unique to this class definition.

For security reasons, it is considered a .NET best practice to design all custom attributes as sealed. In fact, Visual Studio 2008 provides a code snippet named Attribute that will dump out a new System. Attribute-derived class into your code window.

Ronnie Overby
You should cite your source yourself, preferably for this medium at the top rather than the bottom.
Joel Coehoorn
Thanks for adding the amazon link Joel.
Ronnie Overby
:) If you want this to count as 'fair use', one of the legal tests is that it does not diminish the market for the original work. Adding a link to help someone buy the original can help show you're not doing that, but actually helping expand that market instead.
Joel Coehoorn
Of course, IANAL and that by itself might not be enough.
Joel Coehoorn
A: 

Attributes are very good at describing some runtime behaviour of your code that is orthoganal to the code in question. For example, in a class called Customer you would model a customer, right? But you might not want to model or describe the way a Customer object is serialized.

Adding attributes to your Customer class allows you to tell some other part of the runtime how it should deal with your Customer.

MSTest and NUnit makes use of attributes to tell the test framework how it should use classes that define test fixtures.

ASP.NET MVC uses attribute to tell the mvc framework which methods on classes it should treat as controller actions.

So, any place where you have a runtime behaviour that you wish to model attributes can be useful.

Martin Peck
+1  A: 

I believe you mean that you do not use (or frequently use) custom defined attributes ?

In my current project, I make heavy use of custom attributes, but, the fact that you need to keep in the back of your mind, is that using attributes should not be a goal on itself.

It is a tool / purpose to get to a given solution.

I sometimes use custom attributes in combination with a weaver like PostSharp, to decorate methods where some weaving should be applied to at compile-time.

In my current project, I also use attributes to decorate certain types with additional info ... But I believe I've posted about this here before: http://stackoverflow.com/questions/486815/486872#486872

Frederik Gheysels
+2  A: 

Attributes are a form of declarative programming, 'similar' to creating your UI in XAML. It 'marks' pieces of code (classes, methods, properties, whatever) with an attribute so that you can later gather all those pieces marked in a specific way and then do something standard with all of them.

Eg. Consider the scenario where you have certain sections of code that you want to run once each time your app starts. In one model of programming (non-attribute) you go to your main method and explicitly call those init methods. With attributes you simply gather all methods which you've marked with your 'init' attribute, and call them via reflection.

The same pattern holds for actions like serialization, persistence and whatnot...

Pieter Breed
+3  A: 

I like to use attributes as metadata to my code. We have created some simple attributes that let us tag who wrote what code, when, and why. This lets us have both documented changes in code and in runtime. If there are any exceptions during runtime, we can inspect the callstack, look at any attributes on the methods along the way, and track down the people responsible:

[Author("Erich", "2009/04/06", Comment = "blah blah blah")]
public void MyFunction() { ... }


Of course, we could use our source control to look at who checked in what code, but this I've found makes the information more available in the place where you need it. Also, if we ever change source control, that information will not be lost since it is persisted in code.

Erich Mirabal
I did something similar but on an assembly level, where I had a class which the version control created which had an attribute for each commit-message and product/file version so that you could do a dynamic product version history.
Pieter Breed
Interesting system. Could you not just use inline XML docs, though?
Lucas Jones
probably could, however this way we could inspect the assembly from other tools related to the build too using the reflection API, rather than invoking it with a custom API
Pieter Breed
We still use inline XML docs but for creating the help files.These attributes are more for developer to developer or bug reporting.
Erich Mirabal
A: 

I use attributes for the following:

  • Communicating with a plug-in architecture
  • Telling another framework what to do with the code (NUnit, for instance)
  • Adding metadata for use with other code (See PropertyGrid)
  • Mapping objects to databases (See Castle ActiveRecord)
  • When writing my own APIs to allow users to communicate metadata
  • In framework code to tell the debugger to skip over it

Those are off the top of my head. I use them in many other places

Brian Genisio