vendredi 25 août 2017

Clarification about how reflection works internally

As stated in the title i need some clarification about how reflectoin works internally. I doesn't need deep detail about implementation but only an overview of how that mechanism works bheind the scene.

So far i have imagined that all object in the memory is more or less like an XML (sure with a complete different structure and syntax but the concept is the same) with a structure that describe the object and some datas. So in my view reflection is a tool to read and manipulate this object representation (conceptually xml-like).

Recently i have worked in a project where i have two dll, the first dll (i call it A.dll) with some base types (i use BaseA when i refer to them); the second dll (i call it B.dll) with some derived types (i call them DerivedBFromA because all the type here are derived from some BaseA). My project reference's chain is that A.dll does not reference nothing (except some system libraries) and B.dll has a reference to A.dll (and other system libraries).

When i debug the project i can see (using immediate window) every DerivedBFromA object's istantiated and right described by reflection. But opposite to what i'm expecting that is true until the scope is inside B.dll, when the scope goes down to A.dll i can't see the original structure of my object neither with reflection (i see only the strucutre of the corresponding BaseA).

So i start supposing that the object description (that reflection use to read structure and manipulate datas) is not attached to object instance (as i image in my XML-like model of reflection mechanism) but instead objects contains only datas and somewhere typedescriptors (detached from object and stored in dlls) contains only structure description.

For those reason i would like to ask you if somebody could give to me more detail about reflection, so that i can make that topic more clear to me.





Aucun commentaire:

Enregistrer un commentaire