I have a .NET application that generates an XML file via serialization (through XmlTextWriter) and submits the data via https. Recently, they changed something on their end to only accept an upper cased UTF-8 encoding, like this:

           <?xml version="1.0" encoding="UTF-8"?> 
        

Unfortunately, using the .NET classes mentioned above, it generates the encoding string in lower case. I could find one mention of this on google, and they said to have the other company change (not an option here), or override XmlTextWriter. I went with that approach, making heavy use of Reflector along the way. I started by looking at the WriteStartDocument method, but realized that the private StartDocument is the thing that generates the output. It also gets called by the overloaded WriteStartDocument, so I'd need to override that method, too. However, in the private StartDocument method, it uses a bunch of private variables and generates output via another private method, InternalWriteProcessingInstructions. Ugly. At this point I realize that XmlTextWriter is not a class made for inheriting.

Back to Reflector, and I notice that the Encoding.WebName is the property used to write out the encoding string. I now create a descendant class of UTF8Encoding. The class is listed below. Now I just call XmlTextWriter, passing in UpperCaseUTF8Encoding.UpperCaseUTF8 for the Encoding type, and everything works perfectly.

          public
          class
          UpperCaseUTF8Encoding : UTF8Encoding  { publicoverridestring WebName
{ get { returnbase.WebName.ToUpper();
} } publicstaticUpperCaseUTF8Encoding UpperCaseUTF8
{ get  { if (upperCaseUtf8Encoding
== null) upperCaseUtf8Encoding = newUpperCaseUTF8Encoding(); return upperCaseUtf8Encoding;
} } privatestaticUpperCaseUTF8Encoding upperCaseUtf8Encoding
= null; }

I have been reading Dustin Campbell's series, The 12 Days of Refactor! X-mas, with interest. He's a very good writer, and has broken down a bunch of Developer Express features into easy to digest chunks of information.

The episode I linked to above touched on the XML Literal support that shipped with VB in Visual Studio 2008. The one sentence summary of this technology is that it lets the VB compiler translate raw XML in the source code into strongly-typed code using XML classes under the hood. It's a very nice idea, and I encourage you to look at the links to learn a little more about it.

While the VB team thought this was a good idea and added the feature, Anders and the C# team believed that it was superfluous to add such a thing to the C# side. I haven't really made up my mind which group I side with yet. However, Anders is benevolent :-), so he gave us the little-documented PasteXmlAsLinq addin that will take XML on the clipboard and paste it into a file in C# syntax building the XML up using classes like XElement.

In a default install of VS2008, open C:\Program Files\Microsoft Visual Studio 9.0\Samples\1033\CSharpSamples.zip and extract the LinqSamples\PasteXmlAsLinq files. There is a Readme.html file in there that tells you how to build, install and use the addin.

While this isn't the same as VB's support for XML Literals, it does make things easier to work with.

• This still works in .NET 2.0.
• If you just do an Add New Item to add a new Application Configuration File to your project in VS, you can just paste the debugging flags in, and the config file will get deployed to the application directory automatically.
• You can just Step Into (F11) the call to x.Serialize, and you will be taken into the proper generated file. You may want to open the file manually as Scott mentioned, but I find it to be faster to press F11, and then go to the place in the file I want to debug.

In the end, we ended up writing our own serialization for .NET CF due to one too many bugs.

Assume you have a class structure like this:

publicabstractclassBase

{

    privateint id;

    privatestring name;

 

    [XmlElement("id")]

    publicint Id

    {

        get { return id;
}

        set { id = value;
}

    }

 

    [XmlElement("name")]

    publicvirtualstring Name

    {

        get { return name;
}

        set { name
= value; }

    }

}

 
publicclassDerived : Base

{

    [XmlElement("newName")]

    publicoverridestring Name

    {

        get { returnbase.Name;
}

        set { base.Name
= value; }

    }

}

staticvoid Main(string[] args)

{

    Derived d = newDerived();

    d.Id = 23;

    d.Name = "Dan";

    string xml = GetXMLFromObject(d);

    Console.WriteLine(xml);

}

Download the sample application here to play with it.

publicstaticstring GetXMLFromObject(object obj)

{

    XmlSerializer xs = newXmlSerializer(obj.GetType());

 

    // Set up chain of writers

    StringBuilder sb = newStringBuilder();

    using (XmlTextWriter writer
= newXmlTextWriter(newStringWriter(sb)))

    {

        writer.Formatting = Formatting.Indented;

 

        // Remove standard
namespace attributes

        XmlSerializerNamespaces xsn
= newXmlSerializerNamespaces();

        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:

publicclassUrl

{

    [XmlAttribute("address")]

    publicstring Address;

    [XmlAttribute("primary"), DefaultValue(false)]

    publicbool Primary;

    public Url()

    {

   }

}
staticvoid Main(string[]
args)

{

    Url u = newUrl();

    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:

    publicclassPlayer

    {

        privateint number;

        privatestring name;

        [XmlElement("jerseyNumber")]

        publicint 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")]

        publicstring Name

        {

            get { return name;
}

            set {
name = value; }

        }

        [XmlIgnore]

        publicbool NumberSpecified;

    }
The downsides to using this techniques are: