I was experimenting last night with a friend of mine (I would link to him, but he doesn't yet have a blog, the bum) and we came up with a pretty cool solution for application configuration files.  Generally, the practice and recommendation is to create/add an app.config file into your VS.NET project.  The compiler will then take the responsibility of copying the configuration file to the appropriate output directory (e.g. Debug, Release, etc) named after the executable (e.g. MyApplication.exe.config).  Then, when your application needs to access information within the configuration file via AppSettings or a call to GetConfig, it can do so via the ConfiurationSettings (in .NET 1.1) or ConfigurationManager (in .NET 2.0).  All is well, and most everybody is happy.

Suppose, then, that you have several applications that get deployed across the computer (maybe into the same folder, maybe not).  These applications may each require their own app.config file.  What can escalate the issue further and introduce maintenance problems is the concept of Library Assemblies.  Library assemblies (DLLs) will look for settings within their host .exe's app.config file.  If you have a 'family' or 'suite' of tools that share a common set of libraries, you will end up repeating the same settings across a multitude of configuration files for the dlls to read.  This easily gets out of control and it makes troubleshooting an application suite cumbersome to deal with, especially when settings must be updated.

By default, as mentioned, your application will look for configuration settings in a configuration file named after the host executable (e.g. MyApplication.exe.config) in the same working directory as the application.  An exception to this is a COM+ component which will look in either %windir%\system32 or the application folder as specified in the application.config (except on Windows 2000) as discussed here.  You do, however, have the means to override this default behavior on both the .NET 1.x and .NET 2.0 platforms.  This overriding must occur prior to any access to the configuration file, so it's a good practice to include this call at the start of your application.

You simply need to tell the AppDomain where to look and this is done via the simple call:

AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", @"c:\myconfig.config");

Of course, it's probably not a good idea to hardcode the path to the configuration file in your application, so reading it from the command line, a registry setting, or some other known location (but not a config file) might be a good idea.  The cool thing about this is you then can have a single, centralized location for all settings and a single location to edit them to have global effect.  Goodbye several configuration files.