Different techniques for storing application settings in your SharePoint solutions

When building custom SharePoint solutions, you often need to store and retrieve application settings such as connection strings, default values, cache expiry settings, etc. In this post, I will go through a few different options that are available and some considerations you need to make before deciding which way to go.

Application Foundations Configuration Manager
The Application Foundations for SharePoint 2010 includes several useful components such as a service locator, logging utility and application settings manager. The application settings manager provides an API to store and retrieve settings on several different levels – farm, web application, site collection and site. The SharePoint property bag at each level is used to store the values and the unique prefix PnP.Config.Key is used to avoid conflicts with other values in the property bag. The only drawback with this solution is that there is no out of the box GUI for setting and updating the values, so you need to write custom code or use the property bag editor available on CodePlex.

Configuration files stored in the 14 folder
Another option is to store your configuration values in an XML file and deploy it to a subfolder in 14/CONFIG. You can then write a simple configuration settings reader class that reads and caches the values stored in the file. The best thing with this approach is that it’s really easy to deploy your settings to different environments by creating separate configuration WSP packages  that includes the configuration settings files. However, if you need to change a value you would need to update and redeploy the configuration package. Therefore, this technique should only be used for global settings that are fairly static, and doesn’t need to be changed through the UI once the solution has been deployed.

SharePoint list
Another popular option is to use a SharePoint list to store configuration values. You can create a list on the site collection root site called Configuration Settings or similar, and store your values there. There is a handy solution on Codeplex called SharePoint config store that provides a nice API for retrieving the values and it also takes care of caching. Since you’re using a SharePoint list, you can use the out of the box SharePoint GUI to set and update the values. You can also enable versioning on the list to keep track of the configuration changes. The only drawback with this solution is that your settings will be stored on the site collection or site level. For global settings that needs to be available across site collections you would need to use one of the two previous techniques.

Web.config should not be used for storing configuration settings in SharePoint solutions, unless there is no other option available. Unlike a classic ASP.NET application, you are not in charge of the web.config file – SharePoint is. And the only supported option for storing settings in web.config is to use SPWebConfigModification class to register the additions to web.config.

As you can see, each approach has different pros and cons and you should choose the appropriate technique depending on the scope of the setting, and if it needs to be updated  through the UI after the solution has been deployed.

No matter what option you choose, I would recommend that you create a common static configuration settings class with strongly typed property getters to access the settings. That way, you are free to use a combination of the different techniques and, if necessary, to change the underlying storage mechanism for your settings without impacting your code.

7 Responses to Different techniques for storing application settings in your SharePoint solutions

  1. NIce summary Christoffer.

    A couple of things to notice:
    – For Sandboxed solutions of these only the List storage option is available (unless using proxies)
    – The List storage option works over Site Colelections (unless sandboxed) if you can use RWEP or similar approch (a good solution if you need to provide the user with a list-based user interface)
    – Storing config options in 14-hive are read-only, period. It’s a mess synchronizing it over multiple servers.
    – Web.config and SPWebConfigModifications are strongly discouraged. There are several known gotchas where modifications are not removed. Only use it when you are absolutley sure what you are doing.


  2. Anders rask says:

    Regarding SPWCM many bugs were fixed in MOSS sp2. Also the one you mention wictor about not being able to remove was either if you used sections (this is pr design) or if you inserted non valid name (forgot the details).
    Another gotcha with this class is that you cannot mix! If you use SPWCM you need to use it always, if you once modified it manually you should never use it or you will loose those settings along the road when someone decides to use SPWCM.

    Another option worth mentioning is using storing inside sppersistedobjects, and for small solutions just using the propertybag without the locator from SPG

  3. can I acess farm level property bag trough any web service? or through nintex?

  4. Ray Gates says:

    Creating a custom list with Title and a Value allows you to store all your settings in one place. There is no need to create a user interface, since you use out-of-the-box functionality and you can secure the list by using permissions on it.

  5. Pingback: Thinking Enterprise Solutions

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: