Yeah, took me ages to make sense of that too.

But essentially, as I understand it it boils down to this:

Attributes are basically just metadata you can associate with types or methods.
A few of them are recognized by the compiler/runtime, and will have "special" effects. (The Obsolete attribute and a handful others, which actually cause the compiler to emit warnings, or generate special code, or....)

Most are just pure, plain metadata. You can look it up at runtime and act on it, but it doesn't have any effect in itself.

One common use for attributes is in O/R mapping frameworks, you might create a class representing a given table in your database, and give it a custom Table attribute specifying which database table it should be mapped to. Likewise, the class members might have attributes specifying which columns in the table they correspond to. That way, when I save/load objects of this type, my framework can look up these attributes, and automagically map the changes in my object to my database.

Effectively you can think of them as a tag that you use to mark something with, so that you can extract this information later. In .NET, the compiler uses some of these attributes [many of the standard attributes] to make compilation decisions that it would not normally make. An example of this is the ability to explicitly demand data layout [using System.Runtime.InteropServices.StructLayout], which has some serious uses if you do a lot of work with binary data, instead of letting the compiler decide where data goes. Another tidbit is the Serializable interface, which allows things to be serialized, and allows for the definition of transient data as well to reduce bloat when saving. There are tons of such attributes, that do things from raising warnings about the use of deprecated functions, to allowing for conditional compilation similar to C++'s #ifdef blocks.

The custom ones are arguably not as useful, but they can be good if you intend to do some runtime code generation/augmentation, which can make identification of relevant parts much less complicated. Great for when you want to sprinkle some sugar on your code, but you don't want to have to do it every time you need the sugar. For example, many of the persistant object implementations I've seen for C# use attributes to rewrite classes to allow this functionality. Same with C# transactional memory implementations, C# code instrumentation, and C# automated paralellizing libraries. The academic world loves attributes [and java's equivalent] for experimental language extensions.

Quote:
An example of this is the ability to explicitly demand data layout [using System.Runtime.InteropServices.StructLayout], which has some serious uses if you do a lot of work with binary data, instead of letting the compiler decide where data goes.

As a point of pedantry, ECMA-335 says the CLR (specifically the CLI loader) is responsible for choosing the class layout and, in the presence of sequential or explicit layout, consumes that layout. Not the compiler.

But that raises the additional point that the CLR itself is also going to examine many attributes to control its behavior, as well.

In general they're just metadata that can decorate various entities (classes, methods, properties, fields, et cetera) and be examined by various consumers (the CLR itself, the compiler, your code).

One great use for attributes I found was in writing my entity composition framework. At the core I had four parts: Entity, IDataProvider, ILogicProvider, and IGraphicsProvider. Each entity would have each of the other three pieces added to it (in any number) to customize the look and behavior of the object.

Attributes came in when realizing that some logic providers will require that the entity have certain data. And being that I didn't want to hard code that data anywhere, I used attributes instead. I made an attribute that I placed onto an implementation of the ILogicProvider interface that would specify it requires interfaces X, Y, and Z where X, Y, and Z all implement the IDataProvider interface. I also applied a similar attribute to any implementation of the IGraphicsProvider.

Then in my game's initialization I would add all the pieces to an entity and call the Entity.Validate() method. That method would use reflection to extract all the attributes from any logic or graphics providers to determine which interfaces were required in my data providers. Then I would go through all the data providers and make sure that I had anything that was required.

I'm sure there are other ways, but this allowed me to have a very extensible component system that didn't require lots of things to be hard coded.

One namespace:
System.Reflection;

Using custom attributes and reflection, you can expose any given type and its associated methods/variables at runtime. An example is the Lua Scripting in C# tutorial. It gives the basic concept.

-Xy