Understanding .Net Configuration Options

Question

I'm really confused by the various configuration options for .Net configuration of dll's, ASP.net websites etc in .Net v2 - especially when considering the impact of a config file at the UI / end-user end of the chain.

So, for example, some of the applications I work with use settings which we access with:

string blah = AppLib.Properties.Settings.Default.TemplatePath;

Now, this option seems cool because the members are stongly typed, and I won't be able to type in a property name that doesn't exist in the Visual Studio 2005 IDE. We end up with lines like this in the App.Config of a command-line executable project:

<connectionStrings>
    <add name="AppConnectionString" connectionString="XXXX" />
    <add name="AppLib.Properties.Settings.AppConnectionString" connectionString="XXXX" />
</connectionStrings>

(If we don't have the second setting, someone releasing a debug dll to the live box could have built with the debug connection string embedded in it - eek)

We also have settings accessed like this:

string blah = System.Configuration.ConfigurationManager.AppSettings["TemplatePath_PDF"];

Now, these seem cool because we can access the setting from the dll code, or the exe / aspx code, and all we need in the Web or App.config is:

<appSettings>
   <add key="TemplatePath_PDF" value="xxx"/>
</appSettings>

However, the value of course may not be set in the config files, or the string name may be mistyped, and so we have a different set of problems.

So... if my understanding is correct, the former methods give strong typing but bad sharing of values between the dll and other projects. The latter provides better sharing, but weaker typing.

I feel like I must be missing something. For the moment, I'm not even concerned with the application being able to write-back values to the configuration files, encryption or anything like that. Also, I had decided that the best way to store any non-connection strings was in the DB... and then the very next thing that I have to do is store phone numbers to text people in case of DB connection issues, so they must be stored outside the DB!

Answer 1

If you use the settings tab in VS 2005+, you can add strongly typed settings and get intellisense, such as in your first example.

string phoneNum = Properties.Settings.Default.EmergencyPhoneNumber;

This is physically stored in App.Config.

You could still use the config file's appSettings element, or even roll your own ConfigurationElementCollection, ConfigurationElement, and ConfigurationSection subclasses.

As to where to store your settings, database or config file, in the case of non-connection strings: It depends on your application architecture. If you've got an application server that is shared by all the clients, use the aforementioned method, in App.Config on the app server. Otherwise, you may have to use a database. Placing it in the App.Config on each client will cause versioning/deployment headaches.