[Update] My buddy said that this sounded like ramblings in my head so I will update it to be a little clearer :).

Generic names used to protect the innocent….

Why is it that everyone things that .NET Configuration (xml) is now a full fledged programming language?  I can understand the need for configuration and I also understand that if I have to use the configuration to drive the application, it is “kind of cool”, but do we think this is better than the registry, .ini files etc?  I am a bit old school and I like strongly typed objects / code.  I think anything I do in configuration, I should be able to do in code.  The hard part of config is I can’t really walk up to a class / Library and ask “What can I do with you?” and get a straight response. What response I get is “…well most of the time you can do this or that but if you are in this mode you can do something else and you really have no idea what to expect…”.  The reason I am looking at this interesting (at least to me) issue is because I am looking at some code and the configuration for it. This code is a plug-in style configuration that defines the types I can create in configuration. This code has a bunch of objects defined that take XmlNodes but I really don't know what the xml is supposed to look like for each object type. There is a schema, but it just defines a couple of attributes as required and the rest is open ended. Each element is defined genericly and then all the attributes “I assume” represent it's properties. These properties are used to initialize the object in a ListDictionary... hmmm,  the properties are not exposed on the real concreate object.  It has a facade that seems to hide all this goo from me, and I know that most people would just say that using a façade is ok, but I need to dig a little deeper.  How the heck am I supposed to know what type of thing I am using… I really don’t want to treat it polymorphic… I want to instantiate a specific type. Wow I can’t do it… I have to get a “pseudo-abstract” type and then hope that if I look in its dictionary for things that may or may not be there.  I thought this thing was going to save me lines of code. 

Now how should we correct this problem <given that not everyone may not think this is a problem>?  My thought would be to use configuration as just another persistent store for the state of my library / code that I could then change out of band.  I know that Whidbey specifically address some of these issue with the new Configuration namespace design, but how about my specific problem?  We could use the XmlAttributes and persist that back and forth from configuration.  And since the XmlSerailzer supports inheritance with the XmlInclude attribute, you could still do things polymorphic.  I know that someone might say that the XmlSerialzier is slow, but this is configuration, why would we store 10 megs of info in configuration and if we did, maybe a better place for that is an out of band mechanism like SQL Server and we could use the Configuration Management Application Block  to deal with this and use a dataset to transform the data.

Along the same vein, I would love feedback on how much is too much configuration…