Assume you have a class structure like this:

public abstract class Base
{
    private int id;
    private string name;
 
    [XmlElement("id")]
    public int Id
    {
        get { return id; }
        set { id = value; }
    }
 
    [XmlElement("name")]
    public virtual string Name
    {
        get { return name; }
        set { name = value; }
    }
}
 
public class Derived : Base
{
    [XmlElement("newName")]
    public override string Name
    {
        get { return base.Name; }
        set { base.Name = value; }
    }
}

To see the error, call it like this:

static void Main(string[] args)

{
    Derived d = new Derived();
    d.Id = 23;
    d.Name = "Dan";
    string xml = GetXMLFromObject(d);
    Console.WriteLine(xml);
}

Download the sample application here to play with it.

public static string GetXMLFromObject(object obj)
{
    XmlSerializer xs = new XmlSerializer(obj.GetType());
 
    // Set up chain of writers
    StringBuilder sb = new StringBuilder();
    using (XmlTextWriter writer = new XmlTextWriter(new StringWriter(sb)))
    {
        writer.Formatting = Formatting.Indented;
 
        // Remove standard namespace attributes
        XmlSerializerNamespaces xsn = new XmlSerializerNamespaces();
        xsn.Add(string.Empty, string.Empty);
        xs.Serialize(writer, obj, xsn);
    }
 
    return sb.ToString();
}

The key is to create an XmlSerializerNameSpaces object, populate it with empty strings, and then pass it to the XmlSerizliazer. The result is a more compact XML file. Note that this works, despite the comment in the documentation explicitly saying that it isn't supported.

You can also use this class to add your own custom namespaces. This could be useful to prefix certain elements with a certain namespace.

When you create an object with a bool field, that field is initialized and defaulted to the value of false. Under normal conditions, this value will get serialized every time. However, what if we only care about capturing that value when the value is true? It turns out that we can use DefaultValueAttribute. The first thing that may stand out to you is that this attribute lives in the System.ComponentModel namespace, and not in an XML namespace. The online help also mentions that this is used for visual designers and code generators. XmlSerializer also uses this attribute to decide whether or not to stream the value during serialization, since it's really a form of a code generator (more on that in a later post). If the value of the field or property matches the value that you specify in the DefaultValueAttribute, then that property will not be streamed.

Using an XmlAttributeAttribute, you can specify that a certain property will be expressed as an XML attribute instead of an XML element. To demonstrate both of these concepts, see the following code:

public class Url
{
    [XmlAttribute("address")]
    public string Address;
    [XmlAttribute("primary"), DefaultValue(false)]
    public bool Primary;
    public Url()
    {
    }
}
static void Main(string[] args)
{
    Url u = new Url();
    u.Address = "http://testing/";
    string xml = GetXMLFromObject(u);
    Console.WriteLine(xml);
}

This produces roughly the following output (XML namespace information is stripped here. I will show how to do this in code with a future post). Notice that the Primary attribute is not generated because it matches the DefaultValue.

<?xml version="1.0" encoding="utf-16"?>
<Url address="http://testing/" />

The XMLIgnore attribute is used to tell the XmlSerializer that this field is transient, and should not be (de)serialized. The most typical use for this would be to mark calculated fields with this attribute. This is an easy customization that helps your serialization process, but it leaves a bit to be desired. It's an "all or nothing" approach, where the property is either streamed or not.

This MSDN article hints at what to do to get more fine-grained control of this aspect of serialization. Basically, you create a public boolean field or property named propertyNameSpecified for the property you want to control. The XmlSerializer uses this convention to determine whether or not to include the associated property for serialization. Since this new Specified field will be eligible for serialization, be sure to mark it with the XmlIgnore attribute to prevent it from being serialized.

A very simple code listing showing how this all fits together:

    public class Player
    {
        private int number;
        private string name;
        [XmlElement("jerseyNumber")]
        public int Number
        {
            get { return number; }
            // You could add more logic here to only set NumberSpecified based on some criteria
            set { number = value; NumberSpecified = true; }
        }
        [XmlElement("playerName")]
        public string Name
        {
            get { return name; }
            set { name = value; }
        }

        [XmlIgnore]
        public bool NumberSpecified;
    }
The downsides to using this techniques are: 

Assume you have a (stripped down) class definition like this:

And you wanted to read/write an XML file that looked like this:

The key to making this happen is the XmlSerializer class. This is the class that will convert between public properties and XML elements. You can also decorate your class with simple attributes to coerce your class into generating custom XML (i.e. XML attributes, hide or rename elements, etc.).

Here are a couple of helper methods, and a sample that uses them to show you how all of this comes together.

Other references:
XML Serialization in the .NET Framework

The other change is on my blog. With prompting from Steve Trefethen, I made the switch to dasBlog. I had set dasBlog up for our internal blog at my last place of employment, and it worked great. I got tired of the lack of options that .Text provided, so I felt I had to do something. dasBlog provides a couple of features that I really wanted, like searching and better spam prevention. In addition, it's actively being developed.

Converting was fairly painless. I read a post by Scott Hanselman about migrating to dasBlog, and from there I found some code to help automate the conversion. There are several dead links out there, so finding this one was a definite time saver. I changed the code slightly to get categories out of .Text and into dasBlog. I changed the main SQL statement to the one below, and then just added a line of code to add that category information to the dasBlog conversion code. This works for me because I didn't use multiple categories for a post.

SELECT 
  blog_Content.ID, blog_Content.Title, blog_Content.DateAdded, blog_Content.SourceUrl, blog_Content.PostType, 
  blog_Content.Author, blog_Content.Email, blog_Content.SourceName, blog_Content.BlogID, blog_Content.Description, 
  blog_Content.DateUpdated, blog_Content.TitleUrl, blog_Content.Text, blog_Content.ParentID, blog_Content.FeedBackCount, 
  blog_Content.PostConfig, blog_Content.EntryName, blog_LinkCategories.Title AS CategoryTitle
FROM blog_Content 
  LEFT OUTER JOIN blog_Links ON blog_Links.PostID = blog_Content.ID 
  LEFT OUTER JOIN blog_LinkCategories ON blog_Links.CategoryID = blog_LinkCategories.CategoryID

I was worried about old URLs that were used from my .Text blog, but the later versions of dasBlog already do URL rewriting to make that transition absolutely seamless. I also use w.bloggar for writing my entires, so I had to change some settings to get that to work with dasBlog. Lastly, I updated my RSS feed to use FeedBurner.

All in all, I'm quite happy with how things turned out. If you see any problems, please feel free to let me know.

The negative for this book outweighs the benefits, in my opinion. The fact that there is no sample/reference application leaves the reader frustrated. If the design techniques can't even be proven in a simple application that was discussed over 450 pages, how can one have faith to apply the techniques in their own production applications? I searched on the book's forum, but the general attitude there is "If you need a sample, you can't understand all the decisions made to create your own application". My reply to that is "Hogwash". As mentioned earlier, 450 pages were used to talk about why certain architectural decisions were made.

All in all, I would skip this book until the major deficiency of no sample application is fixed.

I checked with him this week as I'm doing more work in this area now, and he told me that the free tool to get this done is called ActiveSync Remote Display. It is part of the Windows Mobile Developer Power Toys, available from Microsoft. I also tested it this week, and I can report that it still works with Active Sync 4.2.