[Mono-list] Graph of a Class

A Rafael D Teixeira rafaelteixeirabr@hotmail.com
Sat, 15 Jun 2002 23:24:52 -0300

>From: "Dwivedi , Ajay Kumar" <AjayKumar.Dwivedi@dresdner-bank.com>
>	I asked a question about the order in which members are serialized
>by XmlSerializer on the DOTNET-CLR mailing list. One of the answers is:
> > The object is serialized as a graph: starting with the root object, top
> > down, fields then properties and *deep* into each field/property.
>Can anyone explain how to obtain this graph?

Im using XmlSerializer heavily on a project at work, and I can say some 

1 - Its at most a PARTIAL graph, because only 'public' fields or properties 
are serialized.

2 - Its commandered by attributes which can make fields/props be ignored ( 
[XmlIgnore]) or output as xml attributes ([XmlAttribute]) instead of as xml 
elements, which is the default.

3 - Subclassing brings even more attributes into play to tell the serializer 
what descendant types to expect in some superclass instance.

4 - A schema with a element having MaxOccurs > 1, is interpreted normally by 
the xsd utility as a request to have an Array, when generating classes to 
correspond to the schema. But normally, I change it to ArrayList, to be 
possible to add elements at runtime.

Recomendation: Play with the xsd utility, it can make class to schema, and 
schema to class transformations...

>Another answer from "Yann Christensen" (probably from Microsoft) was:
> > The answer is that the order is a function of the order of reflection. I
> > believe reflection makes no guarantees but in V1 for C# compiled code
> > you get fields in order and then properties in order as declared.
> > Apparently in VB the declared order and reflection order are not always
> > the same.

When you construct a XMLSerializer, you pass it a root type and it analises 
it with reflection (my hundred-plus hierarchy, takes almost half a minute to 
have a XMLSerializer constructed) AND generates a customized parser/writer 
in a temporary assembly to do the serialization/deserialization (when you 
debug the project you see this assembly being loaded, and when something 
breaks the parsing/writing you can see the generated methods' names in the 

>	Now if this means the order of members returned by
>GetType().GetMembers(), this is not entirely correct. The above theory of a
>graph looks more appropriate.
>	How are we implementing this? What is the order of reflection in

Reflection really have some issues with ordering, at least when reading 
assembly attributes for my GetOptions class (GNU getopt is too low in 
abstraction that Im writing something more object/event-oriented for Mono) 
I normally get attributes with multiple instances, in reversed order 
(looking at the instances values).

But surely, "source" order is what XmlSerializer considers, except for xml 
attributes. Look at this example:

public class Root

int a;

public int b;

public int c;

public int d;

public Child[] children;


public class Child
public int ca;

public int cb;

public class GrandChild : Child
public int cc { get { return cb*2; } set { cb = value / 2; } }

A valid instance may be serialized as:

<MyRoot xmlns="..." c="456">

See as field/properties names are the default tag names, but may be 
substituted, and go into oblivion for collections (this brings limitations 
on what types are allowed to be contained in subsequent fields that are 
collections, as the serializer will use tag names as a bordering criteria).

Sorry for showing you all this complexity, but Im quite sure youll smash 
it. Time allowing, Ill try to help you, at least with test cases from my 
daily usage.

Happy Hackings

Rafael Teixeira
Brazilian Developer

MSN Photos is the easiest way to share and print your photos: