[Mono-bugs] [Bug 78594][Nor] Changed - [PATCH] 2.0 Serialization Callbacks

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Thu Jul 6 09:55:00 EDT 2006


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by kornelpal at gmail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=78594

--- shadow/78594	2006-07-06 09:40:31.000000000 -0400
+++ shadow/78594.tmp.22998	2006-07-06 09:55:00.000000000 -0400
@@ -161,6 +161,42 @@
 support serialization events for classes that implement
 ISerializable. And it makes sense, IMHO, because thoses classes
 can have much better hooks.
 
 I'll look at your code ASAP.
 
+
+------- Additional Comments From kornelpal at gmail.com  2006-07-06 09:55 -------
+Unfortunately life is not that simple.:)
+
+I have added a lot of CallbackOrderInheritanceXXTest (where XX is 
+variable) that behaves exactly I expect: Nothing matters, callbacks 
+are called anyway, in inherited classes the same callback type is 
+called in blocks with base class callbacks firts.
+
+So there is no difference in callback handling of ISerializable. 
+Even field initialization is the same because OnDeserializing is 
+called befor setting filed for non-ISerializable types or calling 
+constructor for ISerializable types.
+
+But I just found something that suggests that nobody should assume 
+anything about fields before OnDeserialized or 
+IDeserializationCallback.OnDeserialization is called:
+http://msdn2.microsoft.com/en-
+us/library/system.runtime.serialization.iserializable.aspx
+
+"The order in which objects are deserialized cannot be guaranteed. 
+For example, if one type references a type that has not been 
+deserialized yet, an exception will occur. If you are creating types 
+that have such dependencies, you can work around the problem by 
+implementing the IDeserializationCallback interface and the 
+OnDeserialization method."
+
+I modified the tests to succeed on MS.NET 2.0 and marked test not 
+succeeding on Mono as Ignored. It think this is how the tests should 
+go to SVN currently. If the callback order ("...B0A0" -> "...A0B0") 
+is different with your instance of MS.NET 2.0 than mine this means 
+that we shouln't use these tests at all because the order is 
+undefined.
+
+(I modified only some things so the easiest way to see the 
+difference is to compare the two diff files.)


More information about the mono-bugs mailing list