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
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.