[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
escriure:
> > > 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