DLL with configuration file

Quote:

1.1 What is Application Configuration Data?

As a developer you deal with application configuration data all of the time. Common examples of this are INI files, XML files, .NET configuration files (aka “.config”), the Windows registry, and command line (argv) arguments. The advantages of configuration files are that they load quickly, do not take up a lot of space, and are easy to edit.

1.2 The Problem

Attempts to create configuration file access schemes do not satisfy the needs of either programmers or end-users. To give a real life scenario I worked for an organization that configured their original programs using the Windows registry API (Application Programming Interface). Later on they developed their own ASP configuration class. At about the same time another group developed an API that fetched the data from a database. Then when ASP.NET came along they started to use Web.config. In a matter of several years the number of configuration data sources grew from one to four! Needless to say getting configuration data often became a grueling task. Here are the three major areas where configuration management can be improved:

API
Developers use a configuration file format that gets their application running in the shortest time possible. However the API for accessing this data is commonly added as an afterthought resulting in an inflexible API. In very small applications this might not be a problem but as a program’s codebase grows the configuration information will often find itself littered throughout the application code.

End Users
Configuration files are usually not written with the end user in mind. Often the configuration options are terse programming terms that only the bravest users dare to change them. This leads to developers having to write complicated configuration file editors or worse, entirely redesigning their original APIs.

Multiple Configuration Sources
As your software matures it is not uncommon for more application configuration types to be added (such as the example I gave you earlier). This often occurs because of merging code from other projects, new improved formats, and moving to different programming platforms. This forces programmers to learn multiple APIs. The end result is code that is neither consistent nor friendly to new programmers. The old configuration files aren't replaced because programmers and their managers are not comfortable with altering mature code. Users that edit the files are resistant to this change because they would prefer not to learn a new file format.

Quote:

5.5 Choosing the right configuration file type for your application

Nini was written to make all configuration file types first-class citizens. This is because each configuration file type has it's own strengths and weaknesses. The list below contains some basic guidelines:

INI
Speed - The file type is parsed very quickly so it is likely to load and save faster than other types.
Readibility - Of the configuration types this is probably the least scary to users. If you are going to have users alter this configuration file manually then I greatly recommend this format.
Installers - INI files are supported by many types of installers (Wise, NSIS, to name a couple). If you need your build to edit these files than this is definitely the way to go.
XML
Speed - The XML parser has a lot of information to load so this is probably the slowest.
Readibility - This format is a bit scary for beginning users to understand.
Support - This is supported by all programming languages so if other applications are accessing data then this is a good type.
Installers - Since there is no standard XML format for configuration files this is not often supported by installers.
.NET Configuration File
Speed - The XML parser has a lot of information to load so this is probably the slowest.
Readibility - This format is a bit scary for beginning users to understand.
Installers - The .NET Framework uses these configuration files for other configurations. I would recommend not using it if it mixes up .NET configurations and your own application configuration options.
Windows Registry
Speed - Retrieves configuration data quickly. The retrieval speed does become slower as the registry becomes increasingly filled with data. This is cited as one of the reasons why periodically re-installing Windows can make a computer run faster.
Readibility - You should use this type if you really do not want users to be able to configure the application. Touching the Registry can cause serious problems so it is recommended that you do not use it unless necessary. However, know that your support staff will have the same problems as users if they need users to tweak configuration settings. Other than that, the configuration file editor is pretty well known and mature.
Installers - Most installers support reading and editing registry keys so this is a good choice.

There is no perfect configuration type because each one has it's own benefits. If you end up choosing a configuration file type that turns out to not right for your situation then do not be alarmed. Nini abstracts what type of file you are accessing so the amount of code that you will have to change should be minimal.

string assemblyFolder;
            if (System.Web.HttpContext.Current != null)
            {
                assemblyFolder = Assembly.GetExecutingAssembly().CodeBase;
                assemblyFolder = new Uri(assemblyFolder).LocalPath;
            }
            else
            {
                assemblyFolder = Assembly.GetExecutingAssembly().Location;
            }
            var myDllConfigAppSettings = ConfigurationManager.OpenExeConfiguration(assemblyFolder);