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

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: 

Zewei Song, Ph.D.
Microsoft Certified Master: SharePoint 2010
Microsoft Consulting Services