[Mono-devel-list] Adding new CultureInfo

Jonathan Gilbert 2a5gjx302 at sneakemail.com
Fri Feb 4 18:45:18 EST 2005

At 03:27 PM 01/02/2005 +0100, Aleksandar Dezelin wrote:
> One simple question: does remoting serialize static fields of a class?

At 06:33 PM 01/02/2005 -0500, Jonathan Pryor replied:
>No.  At least, I do not believe so (and I'm willing to be corrected).

Note that if this behaviour is desired, it's not hard to add it by making
that class serialize itself manually:

class SampleClass : ISerializable
  public static int SomeField;
  public static MyOtherClass SomeOtherField;

  private int instance_int;
  private string instance_string;
  // etc.

  void ISerializable.GetObjectData(SerializationInfo info,
                                   StreamingContext context)
    // the private fields, which are handled automatically by serialization
by default
    info.AddValue("instance_int", instance_int);
    info.AddValue("instance_string", instance_string);

    // the extra values from the static fields
    info.AddValue("SomeField", SomeField);
    info.AddValue("SomeOtherField", SomeOtherField); /* note that
MyOtherClass must also have the [Serializable] attribute */

  private SampleClass(SerializationInfo info, StreamingContext context)
    /* restore the private fields -- again, this would be done
automatically by serialization */
    instance_int = info.GetInt32("instance_int");
    instance_string = info.GetString("instance_string");

    // also restore the static fields
    SomeField = info.GetInt32("SomeField");
    SomeOtherField = (MyOtherClass)info.GetValue("SomeOtherField",

Also note that you still need to have an instance to achieve serialization,
and that every instance will serialize its own copy of the static field. It
might be a possible design to have a special class devoted to the
serialization of all the static fields you need moved from one AppDomain to
another; then, you need only remote that one class.

The ISerializable interface is in the namespace System.Runtime.Serialization.

Jonathan Gilbert

More information about the Mono-devel-list mailing list