The Power of Programming With Attributes

Put them in a separate XML config file?

I kid, I kid.

Seriously, though, attributes often seem like a violation of SOC.

One simple way you can use today is partial classes: put the related attributes that contains only the type name and the actual content elsewhere. You can mix these however you want.

Or you can make a request for a new attribute in the next version of the platform:
[assembly: ApplyAttribute(Type=YourType,Attribute=YourAttribute)].

Or go crazy and put the attributes in xml and... go crazy :D

Just wanted to add that the ApplyAttribute I mentioned should be understood by the compiler and put in the right place at compile time, so that GetCustomAttributes and related methods still work.

What about using .NET 3.5 partial methods ?

The nearest I've got to this experience so far was the realisation that I could add class attributes and even inheritance via partial classes.

What would you do with this feature? Would it be able to work across assemblies? Could you add attributes to other people's libraries?

AOP would be cool, and I can see something like Spec#.

And I can see lots of wizardry being required to stitch it all together again, to give a re-unified view in VS or Reflector.

Wouldn't a list of attributes separate from the source code just be an XML config file? Which is what attributes is trying to avoid I would imagine. I'm guessing a bit as I'm a Java programmer interpreting attributes as an 'annotation'.

Suppose you make an attribute [Template(name="PowerfulClass")] and then stored the Attribute templates in an XML document somewhere:

<Attributes>
<!-- something notation to include namespaces -->
<Templates>
<Template name="PowerfulTemplate">
<Table/>
<DataObject/>
<DefaultProperty name="Name"/>
</Template>
</Templates>

<!-- class specific goes here -->
<Classes>
<Class class="My.Demo.Foo">
</Class>
</Classes>
</Attributes>

Templates could be used for classes with the same behaviour and Class tags could be used for individual tweaking.

Of course you'd have to plugin at runtime so querying on attributes will read from the xml file instead from the assemblies directly. Not sure if that is possible though.

@Kevin: SoC violations are easy. Where attributes drive me nuts are in designer components. It's though to look at the source code when there are so many decorations on the class.

@kokos, @Laurent: I've thought about partial classes, partial methods, but it feels wrong. I don't like to use partials myself. I feel they should only be present when a code-generation tool is used.

@Lars: It hurts my eyes :) But, that was something along the lines of what I was thinking.

With KnownTypeAttribute (System.Runtime.Serialization/WCF), you can declare aspects outside of code since DataContract recognizes that you may not own the code that you need to serialize.

Ditto for exposing a COM+ service over WCF.

See the following:
KnownTypesAttribute: msdn.microsoft.com/en-us/library/ms730167.aspx

Details on COM+ and how to integrate with WCF via the SvcConfigEditor tool: msdn.microsoft.com/en-us/library/ms732009.aspx

I wonder if you can use PostSharp and/or Laos to post-compile the attributes in after the fact based on external config.

The best way I can think of is not actually removing them from the class but instead adding them to a partial class. That would take away them being directly on the class you are editing but won't actually remove them from the class.

The other downside is this will only work for class attributes and won't help for methods/properties/fields/etc ...

This solution would likely be full of gotchas, but they could extend the partial syntax to work for class members as well.

[Awesome]
public partial class Foo
{
[UberMethod]
[SecurityAction...]
public string GetStuff();

[ValidateNotEmpty]
public string Yuck
{
get;
}
}

this would all be syntactic sugar over our current CLR.