[Mono-dev] Serialization strategies for compatibility.

Lluis Sanchez lluis at ximian.com
Tue Jun 6 06:12:35 EDT 2006

El dt 06 de 06 del 2006 a les 10:54 +0200, en/na Mike Welham va
> > > In general I agree, but ISerializable is a bit of a special case due
> > > to remoting. It is unlkiely but conceivable that somewhere in remoting
> > > plumbing (in Mono or another tool) somebody might "if(x is
> > > ISerializable)...".
> >
> > There is no such code in remoting, and even if it was I don't see how it
> > could be a problem. Objects serialized with field serialization or with
> > the ISerializable interface have the same binary format.
> >
> A quick grep shows SoapWriter.cs in
> System.Runtime.Serialization.Formatters.Soap is doing this:
> private void SerializeObject(object currentObject, long currentObjectId)
> {
>     ...
>      if(currentObject is ISerializable || surrogate != null)
> needsSerializationInfo = true;
>     ...
> }

This is not remoting code, it's the implementation of a formatter.
Formatters are general purpose serializers, and remoting just happens to
use them to serialize messages. And of course formatters need to check
for ISerializable. 

> Also, field serialization will only have the same binary format as an
> ISerializable implementation if GetObjectData is careful to make it
> the same.

The binary format is the same. Fields, types and values are codified in
the same way, that's what I mean. Of course, if GetObjectData returns
different member names, the serialized content will be different.

> As you say though, this is not an issue if we're careful to ensure
> that types where (against API) we add ISerializable we ensure the
> serializad binary format matches Microsoft's.
> Best Regards
> Mike

More information about the Mono-devel-list mailing list