How do you serialize an unmodifiable class that contains an interface?

Question

I am trying to serialize an object that contains an interface. However, interfaces cannot be serialized. Normally, I would use something like the NonSerialized tag, but I cannot figure out how to apply this attribute to a class that I cannot modify, such as one of the predefined .NET classes (e.g.: System.Diagnostics.Process).

For example, consider the following code:

using System.Diagnostics
using System.Xml.Serialization;

class Program
{
    static void Main(string[] args)
    {
        try
        {
            XmlSerializer x = new XmlSerializer(typeof(Process));
        }
        catch (Exception e)
        {
            Console.WriteLine(e.InnerException.InnerException.Message);
        }
    }
}

This prints the following result:

Cannot serialize member System.ComponentModel.Component.Site of type System.ComponentModel.ISite because it is an interface.

Is there a way to do any of the following in a class that I cannot modify, such as a system class?

1. selectively ignore child elements during serialization, so that the child element does not get serialized at all
2. mark an element with something that accomplishes the same thing as NonSerialized

I've thought of some solutions like using reflection to dynamically generate a class that contains all the same members as the class to be serialized, doing some type of deep copy, and serializing that. However, I'm curious to see if there is any simpler way to accomplish this serialization task other than going the class generating reflection route.

Answer 1

If serialization of an existing type gets complicated, the best option is always: create a separate DTO model - that looks kinda similar to your domain entity, but which only exists to play nicely with serialization - usually very simple (parameterless constructors, basic accessors, no validation, etc). Then map between them. Otherwise, you'll be playing a game of whack-a-mole with configuring a serializer for a type it doesn't really like.

If you want a game of whack-a-mole with XmlSerializer: you can create an XmlAttributeOverrides instance, configure it by hand for your specific type (adding the attribute instances), and pass it into the XmlSerializer constructor. But this is ugly, quite fiddly, and you must must must cache and re-use the serializer instance (the normal automatic assembly cache/re-use doesn't apply if you use that overload of the constructor). You can obtain (from the XmlAttributeOverrides instance) an XmlAttributes instance per-type or per-member, and then the XmlIgnore property to true as necessary. Frankly, I advise against this approach.

Answer 2

Typically you serialize an object that you are implementing yourself which gives you full control in instances like this. I would create a wrapper object that implements ISerializable and in its constructor accepts a Process object. That way, you can control which fields are being serialized yourself.

Having said that, serializing a an executable process does not seem viable. I'd imagine you would want to serialize an object that contains row data that you then consumer over the other end of the wire (at the time of deserialization). The Process class represents a running instance of code in the system, so it seems strange to be wanting to serialize it.