This project is read-only.

Custom Attribute Object

Topics: Metadata Model, PE reader
Apr 19, 2010 at 12:58 PM
Edited Apr 19, 2010 at 12:59 PM

Hi All,
Custom attributes that are part of the PE Reader unit are loaded as ICustomAttribute that contains structural representation of the custom attribute in term of what constructor it calls and what arguments are passed to it.


When using Reflection, the custom attribute representation contains the actual object model and state rather than structure, so it will know the field/property and its value. If the custom attribute inherit from another attributes, or has default value when not passed in as parameter, interrogating the field/property getter will give you what values are currently belong to them. Take Status attribute above as example, ICustomAttribute will tell me that it calls a constructor with no parameter. If the status default constructor assign its internal CurrentStatus = StatusEnum.InProgress, there is no way for me to find that out the value of CurrentStatus. Same apply if Status attribute has other internal field that were given default value or inherit from another attribute that has other values set.
In the project that I'm exploring, the object state of the custom attribute is crucial and add additional richness for performing static analysis. I'm wondering if there is anyway of getting such information? Or any suggestion on what I can do to achieve this without having to use this parser and Reflection library in parallel? Thanks,Fadrian

May 3, 2010 at 1:42 PM

No response as yet from anyone. Anyone able to help or advice?

Any feedback and comments are greatly appreciated. 


May 3, 2010 at 2:26 PM
Edited May 10, 2010 at 1:58 PM

You can check for assignments to the attribute properties (or the respective backing fields, for completeness) in the ctor bodies that are being called. It's not trivial - it's not even rocket science - and it's more complicated than using reflection.


I'm no CCI expert so I don't know if there is a smarter way. It's just a simple suggestion.

May 5, 2010 at 8:37 AM

The basic problem with the Reflection model is that it assumes that the static analysis tool is able and willing to load and run the code on which the custom attribute constructor depends. If you are able to do this, then using Reflection to instantiate the attribute is probably the easiest way to proceed.

If you cannot run the constructor, or you do not trust the code of the constructor, then you have to restrict the interpretation of custom attributes so that the meaning is obvious from the metadata structure, rather than the state after running the constructor. The latter approach is the one I recommend.