Hi Arjun,

So far as i know, there is no way to control the serialzation order in
the built-in VS serializer.

You can implement your own serializer, that takes care of all specific
features your objects have. (Do you really whant to? and do you really
whant to rewrite it each itme dependencies between objects change?)

The other way is to implement ISupportSerialize with its EndInit().
This function will be called (for the objects that implement it)
after all objects are deserialized. You can postpone all critical
actions (those ones that depend on other objects being already
deserialized) until EdnInit() is called.

Again there is no way to control the calling order of EndInit() for
different objects. Thus, you have two "layers" with uncontrollable
calling order inside each of them: (i) deserialization;
and (ii) EndInit().

----------------------------------------------
Sorry! Sorry!!! only now i understand your problem (I hope).
(But the text above can be still usefull nevertheless. Can?).

I would say, implement a default constructor for Wrapper class
and equip the class with new property WrappedObject, so that
serializer generates:

Wrapper object1 = new Wrapper();
MyClass object2 = new MyClass();
......
object1.WrappedObject = object2;
......

The whole logic must be transferred from the old constructor to
the new property. I agree, consistency will suffer, since wrappers
without wrapped objects can be created, but i see no other way.

What makes me feel uncomfortable: Can it be, that you present
a rather simplified version of your problem? A lot of objects in my
programs have other objects as ctor parameters and i've never had
any problems. Maybe the reason is that both classes (MyClass and
Wrapper) are IComponent-s and the VS Serializer treats them
differently (it must).

HTH,
Dima.

Hello Dima,

Thanks a lot for that piece of information.
Only "MyClass" is an "IComponent". I suppose the code snippet that i
had written before wasnt very descriptive (wrong example). Consider the
example below.
The serialized code looks like this


class Form1 : System.Windows.Form
{
private Type1 object1;

private void InitializeComponent()
{
Type2 object2 = new Type2(object1);
object1 = new Type1();
}
}


but it should actuallly be:

class Form1 : System.Windows.Form
{
private Type1 object1;

private void InitializeComponent()
{
object1 = new Type1();
Type2 object2 = new Type2(object1);
}
}

"Type1" is an IComponent.
"Type2" isnt

Given this, is there any way to control the serialization order ?

Hello Arjun,

I'm afraid you should change something in the object design.
Not because it is invalid, but because MS/VS can not fitt all
imaginable requirements/wishes.

The VS Serializer (i suppose) considers
IComponents as serialization "roots". It starts with Components
and serializes recursively objects that are "used" by them.
An object is considered to be "used", if it is an argument of a ctor,
a value of a read/write property, a member of an ICollection, etc.
What "using" means can be specified more precise by different
attributes.

I do not understand the reason why the Serializer serializes
"object2" in your example. That is why i can hardly understand
what is "thinks" doing this and how to "convince" it to act
differently.

May it be, that "object2" is used by another component
(one different from "object1") ?
I suppose, there must be somewhere an "owner" of object2
that has a rank of a Component and serializing obvject2
is a consequence.

If I new more about your example.

Another idea were to implement all Wrappers as an extension
properties of some IExtenderProvider. In this case the VS Serializer
knows what to do and serializes in a correct order.

Regards,
Dima.