|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
Announcements
Want a new Job?
Chapters
Services
Feature Zones
|
IntroductionThe .NET Framework provides a rich configuration API which is consistent for stand alone desktop applications and web applications. This article provides a brief discussion of XML application configuration in .NET using a stand alone application example. BackgroundMost applications require some configuration parameters which represent durable user preferences (such as a favourites list) or environmental information such as a database connection string or DSN. Windows applications prior to .Net typically stored such information in "ini" files which allowed the application to specify high level sections with name-value pairs of many configuration options under each section. This data format can represent two level information quite easily but is inflexible. There is no possibility of extending the format to include three, four or n many levels of information. The .Net framework includes configuration functionality that loads an application's configuration automatically at run time without programmer intervention. In the case of a stand alone application named blah.exe one must name the configuration file blah.exe.config and the framework will load and parse the config file automatically when blah.exe is run. The .config file format is XML specified here. The benefit of using XML is that the format is flexible, allowing developers to specify their own configuration section names, embed sections in one another to any useful level in a tidy human readable format while also providing an XPath style configuration query interface (see XPath specification at the W3C) which allows a programmer simple access to specific settings in a complex document. The .Net configuration system is highly functional and allows one to configure all parts of the application, including mandating a specific version of the runtime, the remoting configuration, cryptography providers and networking. This article will only explore configuration settings relevant to application data. An Example Configuration FileOne can define custom sections and section groups into which name value pairs can be put. There are several handler types defined in the <?xml version="1.0" encoding="utf-8" ?>
<configuration>
<!-- Register the "settings" section group and it's "font" and "database"
The document root element must always be the Code SampleSo now that we have a configuration file with some simple font and database configuration data, let's read the settings in the application. This is remarkably simple to do for the example configuration file specified above using two classes in the framework: // Font settings are represented by name-value pairs.
The The sample application included with this article queries the configuration file for the font and database settings and puts the values into the GUI components. Play with the configuration file, change the values, comment out some configuration settings and re-run the demo program to see how it responds to the changes. The source code project included with this article demonstrates how to specify some mandatory and some optional parameters, setting defaults for missing optional parameters and showing error messages for mandatory settings. It also shows conversion of some values into numbers and boolean structs, but you surely already know how to do that. ;-) The possibilities for configuration are much more extensive, including writing your own settings validator and loader class such as the one that is shipped with the log4net software. The documentation hints that one can change the loaded configuration and save the changes, but I haven't made a serious effort to find out how. Perhaps another article about this later. Share and enjoy.
|
||||||||||||||||||||||