[Mono-dev] Patch status

[Lionel Cuir]

Hi Miguel,

It seems that you have actually discovered an issue (a bug?) in Mono's 
Soap serialization, and that my patch for DateTime was correct.

Explanation:
I was a little surprised by your return as we had tested our code before 
to provide it (both for serialization and deserialization on same 
platform (Unix or Windows), and serialization on one platform then 
deserialization on the other platform), but these tests were all done 
using the BinaryFormatter.

So, if I create a DataTime and use a BinaryFormatter to serialize and 
deserialize it, it works. But if I do the same with a SoapFormatter, it 
crashes.
Going deeper into the code (see the few lines of code below), the 
problem comes from the fact that, with Soap formatting, the 
SerializationInfo.AddValue(string, XXX) will box the value types XXX 
into objects - this happens at least for both long and ulong.

I didn't have time to explore the problem within the soap formatting 
process but, in the meantime, to temporarily circumvent this problem, 
I've added a hack into the DateTime serialization code (activated with a 
#define HACK_FOR_SOAP_FORMATTER_BUG at the beginning of the file) so 
that DateTime's serialization works in all cases (binary & soap 
formatting). This hack is tested and works well.

Code where the soap formatting problem may be observed:

        void  ISerializable.GetObjectData(SerializationInfo info, 
StreamingContext context)
        {
            if (info == null)
                throw new System.ArgumentNullException("info");

          // ** BUG ***
           // With a BinaryFormatter, this value is considered correctly 
as a long
           // But the SoapFormatter will box it into an object... Or at 
least it's what we see at deserialization time.
          // This is the same below for the ulong, boxed into an object 
when doing soap-based serialization.
            info.AddValue("ticks", this.ticks.Ticks);

            // We serialize the DateTime the .Net 2.x way.
            // Let's store the kind into the left part of dateData, and 
the ticks into the right part.
            ulong dateData = (ulong) ((((long) kind) << 0x3e) | 
ticks.Ticks);

            info.AddValue("dateData", dateData);
        }

I've attached the updated DateTime and the diff, with the hack included. 
I also change the error message that you got earlier to highlight the 
fact the long and ulong values had been boxed into objects with Soap 
formatting. Thanks to update SVN with it.

Regards,
Lionel

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DateTime.cs
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070318/fe2eab5b/attachment.pl 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: DateTime_diff
Url: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070318/fe2eab5b/attachment-0001.pl