c# - Help Understanding .Net Configuration Options -

i'm confused various configuration options .net configuration of dll's, asp.net websites etc in .net v2 - when considering impact of config file @ ui / end-user end of chain.

so, example, of applications work use settings access with:

string blah = applib.properties.settings.default.templatepath; 

now, option seems cool because members stongly typed, , won't able type in property name doesn't exist in visual studio 2005 ide. end lines in app.config of command-line executable project:

  <connectionstrings>       <add name="appconnectionstring" connectionstring="xxxx" />       <add name="applib.properties.settings.appconnectionstring" connectionstring="xxxx" />   </connectionstrings> 

(if don't have second setting, releasing debug dll live box have built debug connection string embedded in - eek)

we have settings accessed this:

string blah = system.configuration.configurationmanager.appsettings["templatepath_pdf"]; 

now, these seem cool because can access setting dll code, or exe / aspx code, , need in web or app.config is:

  <appsettings>     <add key="templatepath_pdf" value="xxx"/>   </appsettings> 

however, value of course may not set in config files, or string name may mistyped, , have different set of problems.

so... if understanding correct, former methods give strong typing bad sharing of values between dll , other projects. latter provides better sharing, weaker typing.

i feel must missing something. moment, i'm not concerned application being able write-back values configuration files, encryption or that. also, had decided best way store non-connection strings in db... , next thing have store phone numbers text people in case of db connection issues, must stored outside db!

nij, our difference in thinking comes our different perspectives. i'm thinking developing enterprise apps predominantly use winforms clients. in instance business logic contained on application server. each client need know phone number dial, placing in app.config of each client poses problem if phone number changes. in case seems obvious store application configuration information (or application wide settings) in database , have each client read settings there.

the other, .net way, (i make distinction because have, in pre .net days, stored application settings in db tables) store application settings in app.config file , access via way of generated settings class.

i digress. situation sounds different. if different apps on same server, place settings in web.config @ higher level. if not, have seperate "configuration service" 3 applications talk shared settings. @ least in solution you're not replicating code in 3 places, raising potential of maintenance problems when adding settings. sounds bit on engineered though.

my personal preference use strong typed settings. generate own typed settings class based on it's settings table in database. way can have best of both worlds. intellisense settings , settings stored in db (note: that's in case there's no app server).

i'm interested in learning other peoples strategies :)