Implementing IPersistStream using .Net Serialization

[reycri]

I have a .Net class (a collection) that already supports serialization.
It implements ISerializable...

Now, I need it to also support the COM interface IPersistStream. Among
other things, I need to be able to pass instances of this class to
methods of queued components (in COM+).

I want to "piggy back" my implementation of IPersistStream to what is
already being used for serialization. So, in the Save() method of
IPersistStream, the object serializes itself using the BinaryFormatter
and writes it to the given stream.

The problem is in the Load() method, I cannot figure out how to make
the object take the given stream and deserialize itself "in place".

Am I missing something?

 

[Mark Rockmann]

You could introduce a second class, which implements IPersistStream. In the
Save and Load methods of this class, you could just use standard
de/serialization code to persist/create instances of your main class.

HTH,
Mark

 

[reycri]

Thanks for your help...

Your suggestion is not ideal since it would have required me to change
the signature of the methods that accept my class as a parameter to the
wrapper class that you suggest whenever that method need an
"IPersistStream-able" object.

But your suggestion gave me the idea that my class should wrap the
implementation class that I used as a data member instead of inheriting
from it. This way, I can deserialize the data member and won't need to
deserialize to "this" which doesn't seem to be possible right now. This
will require more work and is not as clean but I think it will work.

This still begs the question on why the serialization framework in .net
does not allow deserialization to this or self. Maybe this can be done
by overloading the Deserialize method on IFormatter to accept a
reference to the object where the stream should be deserialized:

// existing method
object Deserialize(Stream deserializationStream);
// suggested new method
void Deserialize(Stream deserializationStream, ref object graph);

With the new method, one can deserialize in place:

formatter.Deserialize(stream, this);

This may also mean adding a method to ISerializable that does the
reverse of GetObjectData() which should be aptly named SetObjectData().
Unless the serialization framework can call the (usually protected)
contructor that accepts (SerializationInfo info, StreamingContext
context) on an already existing object.

Is it too late for this?