In Microsoft’s Enterprise Library (successor to the application blocks) it is common to edit an applications configuration in a pretty little tool called the Configuration Console. Offering a similar experience for your applications custom configuration is done by deriving from the EntLib’s base classes and is a time consuming job to do.

I am writing a generic configuration node that can be used to manage any type of configuration expressed in XML. Instead of writing custom code for every property that could be edited at configuration time, you fire up the EntLibXmlEditor node and just ‘have a go with it’. Having a go with it either means managing the configuration file's definition (on a development box) or editing the configuration values itself. a description of how my solution works can be found here.

While stabilizing the project & working it up to its first beta release I came across this post on Scott Densmore’s weblog. It describes a project called ELCCMG (Enterprise Library Configration Console Module Generator). This project does a similar thing: Generating the ConfigurationNodes Enterprise Library uses in order to reduce the time spent on writing trivial code. The status for this project is set on ‘planning’ though compiling the sources already gives you a good idea of how it works.

Though the goal is the same, from what I’ve seen the approach differs.

1.)   ELCCMG uses static code generation to create the configuration nodes used by the Condiguration Console. I’m not a big fan of static code generation and decided to make the EntLibXmlEditor do all of its in configuration time dynamically.

Obviously a matter of taste, though in my opinion it is quite a hassle to regenerate configuration classes every time your applications configuration changes, during development.

2.)   EntLibXmlEditor generates the configuration nodes based on an Xml document. ELCCMG accepts a .net class and expresses its properties in xml when persisting to disk.

Again a matter of taste, though I have to admit that generating nodes around the actual classes you plan to use seems easier. The downside might be that your xml definition evolves into something less easy to edit by hand.

3.)   ELCCMG uses a standalone windows application to edit & configure the behavior of configuration nodes. The EntLibXmlEditor uses the Configuration Console itself to manage the behavior of the configuration nodes.

I think using the Configuration Console’s existing interface is easier to use. ELCCMG could gain flexibility using its UI.

For the EntLibXmlEditor using the Console itself means that it has to be compiled against your set of EntLib dll's, I'm not sure whether ELCCMG will have such a requirement.

I won’t tell you which tool I think is better as both tools are still being developed.

But I'm pretty sure I'll be watching the ELCCMG’s project process & hopefully get some though rolling on how to improve my own EntLibXmlEditor :-P.

Hopefully I manage to wrap up a beta version soon, feels like I’m almost there!!

The GDN Workspace hosting EntLibXmlEditor can be found here.

The GDN Workspace hosting ELCCMG can be found here.