Configuraiton Storage Providers – Smart Client vs Server

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.

If you want to see something around smart client in the next version (or even a 1.1 version) Tom is soliciting feedback.  Send it to him.

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.

Now playing: Queens of the Stone Age - Go With the Flow

Comments (7)

  1. Andy Miller says:

    In the original ConfigurationManagement block I modified the factory to allow tokens in the storage path such as [AppDataPath] corresponding to the values in the SpecialFolders enum. That way I could install the storage file in the user’s application data path. The advantage of the application data path (over isolated storage) is that it can follow the user around if they are on a corporate network. I think isolated storage is only on the current machine.

  2. dls says:

    I think Andy hit on a common solution. I’ve got a modified XmlStorageProvider around somewhere from the CMAB that rooted a path at one of the SpecialFolders enumerations. I got tangled trying to combine the concepts of rooted, relative, and absolute paths, but eventually got myself sorted out. Aside from non-administrator users of user-facing applications, it’s useful for windows services (the local service account is fairly limited in some areas).

  3. Here is the list of links from .NET Musings: Enterprise Library Configuration Part 1 Enterprise Library as non-Admin Manage Application Settings Using Enterprise Library Configuration Logging with Enterprise Library Enterprise Library Logging – Rolling File Sink…

  4. About the ConfigurationContext, it also seems the CacheManager assumes you want to work with the app.config. Is there any way to force a ConfigurationContext upon it?

Skip to main content