Where Should You Store Your SharePoint Solution’s Configuration Data?
This is a common scenario: you are designing a great SharePoint solution and you have some configuration information, such as URLs, connection strings, list names, and so on, that you have to deal with. What should you do?
The easiest and dirtiest way is hard-coding them in code. It maybe fine for a small and quick proof-of-concept but of cause you should not do it.
Next place is application config file. In the case of SharePoint solutions, it is the web.config. Configuration data stored in web.config is not hard-coded, easy to change (who doesn't like NotePad?), and very easy to access from code.
There are other places to store configuration data, SharePoint lists are also popular. The problem is that you have to store the lists’ sites and names somewhere else, otherwise you code would not know where to get the data. An external data store, such as SQL server, is also being used at some customers. Similarly, you have to deal with the data connection information separately as SharePoint lists.
However, in this blog I am going to recommend *NOT* to use any of the approaches mentioned above. To make my point, please check the comparison sheet below:
| Place | Location | Data Management Tools | Backup | Pros | Cons | Should you do this |
| Code | GAC | Visual Studio | Server | Easy | Dirty | HELL NO! |
| web.config | File system | Notepad and so on… | Server | Easy | Multiple copies, hard to sync. Requires to restart app pool when changed. Not being backed up by SQL | No |
| SharePoint List | Content database | SharePoint web UI | Content db | Built-in UI, easy to manage | Have to store location data somewhere else. Too easy to manipulate | Maybe |
| External Data Source | External data source | Custom | Custom | You have full control | Have to store connection data somewhere else. Outside dependency. | Maybe not |
| Property Bag | Content database | Custom application page, utility | Content db | Backed up with content, on site and site collection levels | No built-in UI, have to create your own management tool | Yes |
| Hierarchical Object Store | Config database | Custom application page, utility | Config db | Backed up with config, on farm and web app levels | No built-in UI, have to create your own management tool | Yes |
For storing configuration data for SharePoint solutions, I would like to recommend use either property bags or hierarchical object store, maybe together with SharePoint lists depends on the amount of data you are dealing with. Some people may argue that they do not have built-in UI, actually it could be a good thing in this case, because that means they are not likely to be altered by accident, and it is easier to control access.
Below are some useful links on property bags, hierarchical object store, and application pages:
- Property bag:
- Hierarchical object store:
- Application page:
What about farm level SharePoint solutions? For example one of my customers developed a solution to support their enterprise search, some other customers developed timer jobs. Those solutions are not deployed for a specific site, site collection or a web application. Where should they store the configuration data?
The answer is to store the data in property bag in Central Admin or hierarchical object store, and deploy your application pages to CA. Here is an article about how to do it:
- Get CA's URL: https://www.sytone.com/2010/07/getting-the-central-admin-url-for-a-farm-in-sharepoint/
- Deploy an app page to CA: https://msdn.microsoft.com/en-us/library/ff798467.aspx
Zewei Song, Ph.D.
Microsoft Certified Master: SharePoint 2010
Microsoft Consulting Services