Xml Serialization

I was just reading an item over at Daniel Cazzulino’s blog on XmlSerialization. He gave a nice overview of how xml serialization works, and gave a great tip on how to supress the deletion of the temporary files that are created so you can look at the gory details yourself. As I mentioned in the comment I made on his blog, if you use one of the overloads for the XmlSerializer constructor other than the one that just accepts a type you create a new temporary assembly each time you create a new serializer. If you want to use these constructors either pay the performance penalty, or don’t create a new one each time. Below is an example console application that shows this problem. You need to create an app.config file and make the entry noted by Daniel in his blog to supress the deletion of the temporary files. They will be created in your current user [Local Settings]\Temp  folder in the case of this console app.

I’ve been looking into XmlSerialization recently for the latest code generator I’m working on. I want to save the “settings” entered by the user for a particular generation, and since my generators make such extensive use of meta-data from other applications I have vowed that form now on I will make MY meta-data accessible also. In the past I have used binary serialization, which is great (in that it preserves full type fidelity, deals with circular object references etc) except that when you make changes to private members you can nolonger de-serialize objects from the “old” format (no backwards compatability), and the meta-data for your application is not accessible to others. Having experimented with xml serialization in the past I was aware of some things that could not be serialized, but I pressed on with writing my application, strong in my belief that I could “make it work“ when the time came. When the time DID come and I looked at the resulting class that needed to be serialized I relized that there was no way I was going to get it to work without a major re-factoring. Instead I decided to implement the serialization code myself. It took about 30 - 40 lines of pretty simple code. I’m happy with the way it turned out, as I would rather re-implement XML serialization than have to butcher my object model to make it fit. The lesson I learned was to plan for xml serialization up front, or be prepared to implement a serialization mechanism yourself.

Here is the console application code for showing the (potential) problem with calling the overloaded constructor of the XmlSerializer class.

using System;
using System.Xml.Serialization;


namespace XmlSerializationTest
{
class Class1
{
    [STAThread]
    static void Main(string[] args)
    {
        int i = 0;
        for (i = 0; i < 10; i++)
        {
            CreateNewCustomerAndSerialize();
        }
    }

    protected static void CreateNewCustomerAndSerialize()
    {
        Customer newCustomer = new Customer();
        newCustomer.CustomerAddress = “This is an address”;
        newCustomer.CustomerId = 100;
        newCustomer.CustomerName = “Jane Doe”;
    

        System.Text.StringBuilder output = new System.Text.StringBuilder();
        System.IO.StringWriter outputWriter = new System.IO.StringWriter(output);

        // doing it this way causes 1 temporary assembly to be created
        //XmlSerializer mySerializer = new XmlSerializer(newCustomer.GetType());

        // doing it this way causes a new temporary assembly to be created on every call to this method
       XmlSerializer mySerializer = new XmlSerializer(newCustomer.GetType(), “fooNamespace”);

       mySerializer.Serialize(outputWriter, newCustomer);
    }
}
public class Customer
{
    public string CustomerName = ””;
    public string CustomerAddress = ””;
    public int CustomerId;
}
}