Zen of Settings: Part 1

Few if any applications are developed that don't find some need for storing state in a storage location of some type. It's been that way under Windows going back to Windows 16 when all we had was .INI files as a convienent place to put data that didn't fit into the notion of a data file. .INI files were easy to understand, easy to edit, and without any significant structure. Trying to store hierarchical data or binary items was difficult at best.

Along comes Windows 95 and with it the concept of the Registry. This storage vehicle was part of the operating system (unlike .INI files) and provide both for structured and data type based storage. Initially it was greeted with a lot of enthusiasm and the registry is handy for data that might have gone into a .INI file in the past. However, it had a soon-to-be-realized and now commonly understood weakness; it was susceptible to corruption that was hard to fix. Whereas the .INI files of the Win16 years could be edited by a user with Notepad, the registry required launching a specialized application (RegEdit) and navigating a tree structure of data. Delete or edit the wrong thing and your computer might not boot the next time, or applications might behave badly or crash.

Not the kind of thing you want to have your end users modify while talking with your Tech Support team on the phone.

But the registry and INI files were all we had up until .NET 2.0 unless you wanted to roll your own. Many did just that by embracing XML as a file format that combined the easy to edit features of INI files with the structured and hierarchical layout of the registry. Of course, it also meant spending time writing essentially plumbing/infrastructure code to read/write the XML, validate its format, handle migrations of older to newer formats, and so on.

But what about app.config in .NET 1.x? Isn't that a replacement for INI files and the registry?

Yes and no. Yes because it is XML based and there was some support built into .NET to allow a developer to read data from the file for an executable. Its downside and it's a whopper is that app.config files are intended to be read-only. They're great for storing switches, configurations, commands and other static items that control how an application launches and operates. They're terrible at handling dynamic, runtime data generated as the application runs. Some developers resorted to storing the runtime data in the app.config by rewriting it on the fly. But Microsoft didn't recommend this and most developers decided not to go down that road.

With .NET 2.0, Microsoft unveiled a new technology in the System.Configuration namespace wrapped in the ApplicationSettingsBase class. This system was designed to allow developers to create XML based (by default) settings objects that could be read from/written to, interact with app.config and amazingly support upgrades of the underlying file from version to version automatically.

You'd have thought it would have been one of the top touted features of .NET 2.0. Sadly, and for some unknown reason, it was buried inside the framework and only intrepid souls stumbled onto it. To make matter worse, the documentation around the classes is thin and it left many questions unanswered.

I'll take you on a walk through the ApplicationSettingsBase class over the next few posts. Stick around and you'll be a Zen master.. er.. Settings master by the time we finish.

Posted by Mark M. Baker at 11:26 PM  Permalink