Custom configuration section handlers in .NET

Every day of developing in C# brings me more and more amazement at what Microsoft created with the .NET Framework. Today's thing used: custom configuration section handlers.

Configuration files in .NET are amazing just by themselves before you take into account creating your own section handlers. We're creating an application at work that will host multiple instances of itself in the same folders of ASP.NET. This is easy to do, just make sure you know what instance you're using when you execute a page, however it made an annoyance when you have configuration settings that can change per instance and no way to separate the instance configuration settings by separate configuration files. There are no built in configuration section handlers in .NET that can effectively repeat the same config settings but with a top-level key separating them. So what did I do? I created a new configuration section handler for my instance configuration settings.

My end result was that I wanted this





Looking into it, there is a single interface you have to implement, IConfigurationSectionHandler which has only one method:
object Create(object parent, object configContext, XmlNode section)

At the time of requesting your configuration section in code, the Create method of your handler is called. It expects an object in return that represents the data in the configuration file. Just parse the XML node it passes to you, create an object to do lookups on the XmlNode and I had a configuration section handler that handled the config section. Incredibly simple and it makes the configuration file format for my application so much easier to read and understand.

For some examples of a custom config section hadnler, check out GotDotNet's October Feature User Sample winner. They're in no way complex (neither is mine), but it just demonstrates the flexibility and usefulness of .NET configuration files.

5 comment(s)

joshua wrote on January 23, 2008

I'm not crazy about a lot of things in ASP.Net, but I really love the configuration files, if only for the authentication handling. It's so much less kludgy than doing it the old way in IIS 5.

I'd like to hear what in ASP.NET you don't like. I'd also like to hear what (if any) web programming environment you prefer over ASP.NET.

joshua wrote on January 23, 2008

I suppose I should have prefaced my statement by saying I think ASP and it's .Net progeny are the best thing going in web programming languages. Although, I don't think PHP is too bad.

My main complaint with ASP.Net is that I can't tweak how HTML is generated in a lot of cases. I would like to get compliant markup out of the calendar control, for instance, but I can't.

The other big one is the I am really not keen on ADO.Net. I really love ADO.Net as a data access library. However, "the next evolution of ADO" is such a misnomer. ADO has stripped away with much of what made ADO so slow and unwieldy: the myriad supported interfaces. Whether it was LDAP, AS/400 program calls, or just reading from SQL, ADO was happy to oblige.

It's so hard to get developer buy-in when they see that ADO is no longer a universal data access object, and rightfully, they assume it's a step backwards. I know this is more of a documentation/marketing issue, but it *really* needs to be taken care, imo.

So I guess I have few complaints with the technical aspects of ASP.Net, and it's a huge improvement over ASP, but I have some real problems with Microsoft shooting me in the foot when I try to pitch it for our projects. Between muddled marketing about "web services" and a *really* bad "Intro to ASP.Net" Official Microsoft Course, it's hard to get acceptance, at least within my org, for ASP.Net. Normally, I wouldn't consider marketing part of a platform, I think it makes sense in this case.

...I should have prefaced my statement by saying I think ASP and it's .Net progeny are the best thing going in web programming languages. Although, I don't think PHP is too bad.

I definitely agree with your the first part of your statement, but I hold abstinent to my opinion that non easily-readable languages are a bad thing, hence my dislike for C, C++, Perl and PHP (although PHP is MUCH less bad than the rest). I really dislike languages that use increidbly cryptic characters to mean very common things, creating a very "elitist" language. For instance, take Forth (found it on slashdot today). What the hell does all that mean? (well I can decipher most of it, but it takes a lot of work). Again, just an opinion on language choice, I just prefer the easier to read Java/C# style languages.

My main complaint with ASP.Net is that I can't tweak how HTML is generated in a lot of cases. I would like to get compliant markup out of the calendar control, for instance, but I can't.

Enter one of the great things about ASP.NET. If you don't like the controls that are given to you, you can create your own. I've done my fair share of server control creation, and without it I would definitely like ASP.NET a lot less. However, if you're unhappy with their calendar control, take a couple hours one night and write your own, it's not terribly difficult (and when you get stuck, use Anakrino).

It's so hard to get developer buy-in when they see that ADO is no longer a universal data access object, and rightfully, they assume it's a step backwards.

In my opinion, ADO.NET is so much better than ADO you can't even compare the two. Write your own abstraction layer (or use one of the myriad of products already created) and you can have a super-fast, super-generic data access system. As far as ADO.NET not supporting all the crap (yes, crap) that ADO supported, I'm glad. If you want access to LDAP, use DirectoryServices. Combining everything together makes a jumble of pure garbage that is written to the lowest common denominator and ends up exposing so little for each specific data source that you can't always do what you want to do.

Between muddled marketing about "web services" and a *really* bad "Intro to ASP.Net" Official Microsoft Course, it's hard to get acceptance, at least within my org, for ASP.Net.

True, true. Apparently anywhere there is XML involved, it's .NET (the idiot who screams Developers! Developers! while sweating his armpits off says so). That does definitely make it hard for people who are not "in the know" with .NET to understand what it really is. At Kemper, we have had absolutely no trouble pushing .NET and writing a number of applications in C#. In fact, we opened a new department in the formerly all Java house that is Kemper that is focused specifically in using .NET and Microsoft technologies. We made it happen, so can you. :)

joshua wrote on January 23, 2008

It's interesting that you mention Forth. I had seen it on slashdot the other day as well. What the hell is going on with that language? When I look at it, it reminds me of the .Net CIL.

However, I'm sure forth (being stack oriented) is particularly well-suited to os-less situations, like the Open-Firmware spec, or even color forth itself.

I just couldn't see using it for desktop applications, though. Maybe I'm too dumb, but I can't seem to wrap my head around the idea that you could reassign "9" to increment "1". It would be really easy to get screwed up, to say the least.