Not this kind of XML

VirPack has me working on an application that needs a user administered list of options for people to choose from. It’s a fairly simple thing that doesn’t require relational tables so I thought I’d toss it into XML.

Now, C# deals with XML really well. Almost everything, if you just ask nicely, will be quickly and easily packed off into XML the framework with just a few lines of code.

String path = Server.MapPath("~\\myfile.xml");
using (FileStream sourceFile = new FileStream(Server.MapPath(path), FileMode.Create, FileAccess.Write))
        {
            XmlSerializer serializer = new XmlSerializer(typeof(Foo));
            serializer.Serialize(sourceFile, bar);
        }
        bar = null;
        using (System.IO.FileStream sourceFile = new System.IO.FileStream(path, System.IO.FileMode.Open, System.IO.FileAccess.Read))
        {
            System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(typeof(Foo));
            Foo bar= serializer.Deserialize(sourceFile) as Foo;
        }

As simple as that I’ve packed my class off to be serialized and then unserialized it. Three lines of code is hard to beat for XML serialization and deserialization. “Foo” is a user defined type, however, and my particular task being the population of a drop-down list, no such complexity was required. Yet, when I tried to feed a List of ListItems into the Serializer everything broke.

//This breaks
System.Xml.Serialization.XmlSerializer listSerializer = new System.Xml.Serialization.XmlSerializer(typeof(List));
//This too
System.Xml.Serialization.XmlSerializer typedListSerializer = new System.Xml.Serialization.XmlSerializer(typeof(List<ListItem>));

This has to do with how C# deals with collections. Serialization requires a root level node and a collection, despite having an appearance of such, has no root level information. It is a collection, not a collection bounded by something else and XML serialization requires that something else.

So C# has a hackish workaround. The ListItemContainer class is a simple type that contains a List of ListItems.

//This works
System.Xml.Serialization.XmlSerializer listSerializer = new System.Xml.Serialization.XmlSerializer(typeof(ListItemContainer));

Of course, not everything you’ll wish to serialize in a list will be a list item, but the fact that C# had to create it’s own little wrapper class should be a clue for developers. Getting a collection into XML requires a wrapper class; it’s as simple as that.

Would it have killed them to document that though?

People familiar with C# know that C# supports the inclusion of user defined controls called WebControls.  These are more or less very simple C# programs which can be man-handled by another bit of C# code.  They’re handy for making your code modular: you might design a web-control that takes and validates a credit card number, for example.

But WebControls are notoriously tricky beasts and over the course of the last few weeks I’ve come to understand that one of the reasons for this is that they don’t behave quite the way you might expect them to when they are serialized and deserialized.

Most C# serialization occurs behind the scenes in something called the ViewState.  For those of you who have no idea what that means, ViewState is C#’s rather clever way of persisting the things on a webpage so that it feels a little more like a desktop application.  The long and the short of its behavior is that things get serialized into the ViewState just before rendering and de-serialized back out of ViewState on the next request as part of the load step.

Most controls go into the ViewState… but WebControls don’t.  At least, they don’t go in there by default.  Presumably you can create custom ViewState serialization for them; I have not tried this.  Instead, I serialized my WebControls very simply into Session and coded that storage into a property.  My code looked something like this

private Widget InternalWidget
{
	get
	{
		Widget result;
		if (Session["Widget" + this.UniqueID] != null)
		{
			result = Session["Widget" + this.UniqueID] as Widget;
			if (result == null )
			{
				result = WidgetFactory.Create();
				result.Arguments = InternalActivePortlet.Arguments;
			}
		}
		return result;
	}
	set
	{
		Session["Widget" + this.UniqueID] = value;
	}
}

Now, as expected, none of my EventHandlers persisted when the WebControl came back out of its session serialization.  The object that comes back from serialization is an entirely new object; the old one has been destroyed.  As a result, the event handlers in the deserialized object point to null function pointers.  C# doesn’t throw an error when you call a null function pointer, however; it just goes on its merry way and does nothing.

But the function pointers – even though they now point to null objects – remain.  C# remembers a great deal more about the session-serialized object than one might think including – and this is the part that really threw me – the fact that it’s already been through the ASP parser.

I had expected, since my event handlers weren’t working when the WebControl came back from Session, that the events themselves were gone and that therefore the object returned from session was new — as if it was programatically created for the first time.  This is not the case.  When you programatically create a WebControl for the first time it’s ASP file is parsed and event handlers are set up based upon the code there.  When you deserialize a WebControl from session, however, C# remembers that it has already dealt with its ASP code and does not do it a second time.

Consequently, none of the event handlers defined in the ASP work either.

I expect that all of this seems rudimentary to more experienced C# developers, but to me it was quite a mystery and it took me some time to work out the above logic.  Hopefully this will aid some neophyte coder working through the same issues I had.

On a totally unrelated note: I need to find a decent code display plugin for WordPress…