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

[bugzilla-daemon at bugzilla.ximian.com]

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-04 10:06:44.000000000 -0400
+++ shadow/78594.tmp.12606	2006-07-05 13:39:52.000000000 -0400
@@ -95,6 +95,41 @@
 ISerializable.OnSerialized
 Plain.OnDeserializing
 Plain.OnDeserialized
 ISerializable.OnDeserializing
 ISerializable.Ctor
 ISerializable.OnDeserialized
+
+------- Additional Comments From kornelpal at gmail.com  2006-07-05 13:39 -------
+I've done some modifications to corlib.diff:
+
+Your assumptation was that "MS.NET calls the serialization ctor 
+after OnDeserialized, thus the instance data is not initialized" but 
+this is wrong altough I was unable to find out the real cause. This 
+even may be a bug in MS.NET or in the test case. But that cannot be 
+determined until we get to know what causes it. So I removed code 
+that implemented this weird behaviour.
+
+Added support for an 
+internal "Mono.Internal.OnDeserializedAttribute" attribute in 
+profile 1.x that has to be non-public, sealed, based on Attribute 
+and be in the same assembly as the type. If this patch is approved a 
+mcs/build/common/OnDeserializedAttribute.cs should be added for use 
+only by our class library to support serialization compatibility 
+with MS.NET.
+
+I reallized that not all of the tests succeeded on MS.NET so I 
+modifed them to match MS.NET behaviour. I think that serialization 
+is a so basic part of the framework that we should match MS.NET 
+behaviour.
+
+Added several tests that can be used in profile 1.x as well, don't 
+assume so much things and prove in addition that there is no 
+difference in callback type order, the difference is only in the 
+order these callbacks are called on object instances.
+
+And I marked test with Ignore that currently fail.
+
+Despite the differences I think this patch can be used because this 
+difference in callback order causes little difference in overall 
+behaviour and may be difficult to fix because the cause of this 
+different order is probably in the core of serialization.