My Architectural debate on attributes (DotNet)

I really like the concepts of object orientation. Still, the longer I work with it the more and deeper my appreciation gets.

But lately, I have this tug that just won't go away. Something that is bothering me more and more. Something that just doesn't feel right. It is where Microsoft is going with the usage of attributes in the DotNet Framework.

Isn't "seperation of concerns" one of the main concepts of object orientation? Isn't one of the nice things of this that an object is or at least should be unaware of how it is used?

So why is it than that I have to add more and more attributes to my classes just to be able to use them? You must know what I am talking about. Just think about the "Serializable"-attribute. I don't change anything to the class. It was serializable allready but now I have to decorate it just to be able to use it in that way. Why? Same for exposing objects as services but also something trivial as security or needed permissions. Sure I can live with this but it really seems to be hot to use attributes these days. Think about the Enterprise Application validation block. I really consider those attributes to be a poor mans solution. (Note to myself: publish a proper concept for validation. Without attributes that is.)

What's wroning with "old fashioned" interfaces or exceptions?

If you would aks me I would have them ask Scott for permission for every attribute they want to add to ever wildgrowing list of attributes in the DotNet Framework.

That reminds me, the same is happening with .config-files. But fortunately that has been noticed by the community and Martin Fowler wrote an excellent article about this abuse.