I have had a few questions on this issue so I thought I would post some random thoughts. On the server, controlling where you have the external file (using the supplied XmlFileStorageProvider that we shipped) is not a problem, we support a absolute or relative path. Giving correct file permissions etc on the server is not a problem, yet on a smart client application this is a totally different story. When you install your application in the Program Files directory, (you are doing this aren’t you? you don’t want to be “designed for Windows”?) having a relative path writing to that folder as a non-admin is a big no-no. Like I said before, the XmlFileStorageProvider supports absolute paths, yet on a client machine how do you know where the Application Settings for the logged on user is? There are a few possibilities on how to do this: you could look in the registry / Environment Variables and fix up the configuration file in an action in your MSI (yuck); create an IsolatedStorage StorageProvider so that configuration is always stored in the correct place (one day I hope to do this, or one of you guys could do it); store the configuration to an assembly and read it as a resource (sounds fun and cool interesting, but I think this only helps you on reads); another possibility that exists that you don’t have to change or write any new code for Enterprise Library is to use the ConfigurationContext and not the ConfigurationManager.
I want to have a small discussion about the last suggestion here and I will post a detailed explanation later. The ConfigurationManager assumes you want to work with the app.config for the current AppDomain. When your application is in the Program Files directory you have all the issues we discussed above. Now even if you do some of the options above, you can’t write to the app.config file. This is where the magic begins and the ConfigurationContext can be used. This option allows you to tell it what file you want to use that contains the configuration meta-data. So using this option you take on a little more responsibility and have to create the ConfigurationContext based on a specific file and use it [the newly created ConfigurationContext] for your specific scenario. This allows you to use relative paths and store all these files under the Application Settings for your application and not worry about the privileges since the user should have permissions for that directory.
Also, let me know what you want me to focus on (should I keep focusing on Configuration, do something on Data Access / Logging etc.). I am open to suggestions.