First, let's look just at the title of this question. It looks you are missing something important.
Let's look at all possible targets of the attributes. Please read this:
http://msdn.microsoft.com/en-us/library/system.attributetargets.aspx[
^].
All those targets are classified into Assembly, Module, all types, members of some types and parameters (I include return here). Five groups, 15 different targets. There are no instances of anything. The members can be static or not, it does not matter. Now, why? Because these objects exist before run-time is even started and are described as
meta-data. These objects are created by the end of the loading and exist before JIT compiler (
http://en.wikipedia.org/wiki/JIT_compiler[
^]) starts its work. No instances of any objects are created, and no code is compiled into the native instruction set yet, but the meta-data is already there.
Everything else is created later, during run time. The run time is unable to modify any meta-data of the code. (Not exactly; this is so if we forget about
System.Reflection.Emit
: you can add some code during run-time and hence add to meta-data. Likewise, you can load another assembly, and that assembly will have its own types, which is trivial though. Let's not consider such cases for simplicity — they are pretty much irrelevant.) At the same time, run-time code can retrieve any meta-data from the very beginning of it.
So, the thing is: attributes are meta-data, nothing else. This is a custom "additional" meta-data. They can be applied to anything which can be used as meta-data, but nothing else.
So, here is a quick answer to your question:
what you are trying to achieve is not possible in principle, makes no sense.
Perhaps your approach should be different: you have to explain the ultimate goal of your activity. What kind of functionality do you hope to provide? Maybe the solution can be found, but it should be pretty far from the line you are trying to think along.
—SA