config files - how to avoid clutter?

[Marty McDonald]

Many of an app's classes could read the config file. The config file could
contain many elements, and it will be difficult to know which config file
entry belongs to which class. I could adopt a naming scheme for the
elements. But am I limited to using the <appSettings> element for my
settings? It would be good to have elements such as <myClass1Stuf f> so that
it's easy to tell which settings go with each class. But whether I put
<myClass1Stuf f> in the <configuratio n> element or the <appSettings> element,
I receive configuration errors. Does anyone have good ideas/suggestions for
keeping the configuration entries manageable? Thanks!

[Jay B. Harlow [MVP - Outlook]]

Re: config files - how to avoid clutter?

Marty,
Go ahead and create a section new sections in the app.config file.

There is a predefined configSections section in the app.config that you use
to define new sections.

Something like:

<configuratio n>

<configSections >
<section name="myClass1S tuff"
type="System.Co nfiguration.Dic tionarySectionH andler, System" />
<sectionGroup name="environme nts">
<section name="productio n"
type="System.Co nfiguration.Sin gleTagSectionHa ndler, System" />
<section name="developme nt"
type="System.Co nfiguration.Sin gleTagSectionHa ndler, System" />
</sectionGroup>
</configSections>

<appSettings>
<add key="key1" value="value1" />
<add key="environmen t" value="producti on" />
</appSettings>

<myClass1Stuf f>
<add key="key1" value="value1" />
</myClass1Stuff>

<environments >
<production value1="xyz" value2="abc" value3="edf" value4="ghi" />
<development value1="xyz" value2="abc" value3="edf" value4="ghi" />
</environments>

</configuration>

If you inherit from DictionarySecti onHandler you can easily change the key
or value in your section. I've derived from DictionarySecti onHandler to
change key/value to plugin/type in a few of my projects.

I use the above environments section to define each of my environments,
Production, QA, Test, Development. Where each environment points to the
correct database servers, web servers, message queues, printers any 'per
environment' settings. The appSettings/environment setting is used to
identify the current environment in use.

You then need to use System.Configur ation.Configura tionSettings.Ge tConfig to
get your section, which returns an object based on the type of section
handler defined for that section (usually HashTable, but can be other object
types.

See the following on how to create new sections via the configSections
section.

http://msdn.microsoft.com/library/de...onhandlers.asp

and:
http://msdn.microsoft.com/library/de...ionsschema.asp

Also read about the System.Configur ation.Configura tionSettings class and
other classes in the System.Configur ation namespace.

Hope this helps
Jay

"Marty McDonald" <mcdonama@wsdot .wa.gov> wrote in message
news:OUTwFcCaDH A.1640@TK2MSFTN GP10.phx.gbl...[color=blue]
> Many of an app's classes could read the config file. The config file[/color]
could[color=blue]
> contain many elements, and it will be difficult to know which config file
> entry belongs to which class. I could adopt a naming scheme for the
> elements. But am I limited to using the <appSettings> element for my
> settings? It would be good to have elements such as <myClass1Stuf f> so[/color]
that[color=blue]
> it's easy to tell which settings go with each class. But whether I put
> <myClass1Stuf f> in the <configuratio n> element or the <appSettings>[/color]
element,[color=blue]
> I receive configuration errors. Does anyone have good ideas/suggestions[/color]
for[color=blue]
> keeping the configuration entries manageable? Thanks!
>
>[/color]