Reminded that ISerializable != XmlSerializable
So I thought I'd replace an explicit IConfigurationSectionHandler by making the relevant configuration object nice and neatly serializable via xml. I've done this a couple times previously, it just took some twiddling with the various serialization attributes, a little ISerializable and passing in some extraTypes to the XmlSerializer.
This one was a little different because a couple levels down in the object graph I expose some nested System.Uri fields. System.Uri doesn't have a default ctor with zero arguments, much to XmlSerializer's chagrin. Not that big a deal I figured, I can derive my own XmlUri or whatever and add a default ctor with no params and have that instantiate from localhost. Not great from a design perspective as it goes against the original reasons for not having such a ctor in System.Uri. No matter, I couldn't seem to find a combination that the compiler agreed with once I added the deserialization ctor. Even though I wasn't calling base() it was acting like I was. I reflectored down into System.Uri and it's marked ISerializable/MBRO, but XmlSerializable has requirements beyond that.
So I guess where I ended up was I was either going to need to wrap the entire System.Uri interface in my xml serialization-friendly class (which seemed like more work than this really should require/is worth) or change the design of my config class to work around it (XmlIgnore the Uri member accessors, proxy them through plain old string members that would be the serialization endpoints). The latter seems to encompass what I really end up wanting to do (I just want the end url serialized, not all the bonus functionality in System.Uri that I use elsewhere), but I'm thinking of doing the wrapper just because I may come to this again--and the wrapped class will basically be doing the same thing as the reworked config, just internally.
I'm wondering a.) if I'm just missing the exact right xml attribute to remove this as an issue or b.) just massively bungling something with my original derived approach. I'm having a hard time believing I've never derived from a class with a hidden default ctor, so I don't think it's b., but who knows.