다음을 통해 공유

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:

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

Comments

  • Anonymous
    April 02, 2012
    I don't agree that the Property Bag or Object Store is the best place for this. I would rate those as Maybe and always use a custom list. Why? The list has it's own UI you don't have to code for, it's simple to access the data and it's just as flexible as both of the other options (data is stored in the content databases so no special backup needed). Every developer knows how to read from a list. Not many know how to access the property bag or object store plus you have to build a custom UI for each of those.

  • Anonymous
    April 03, 2012
    That's a good argument Bill. But where do you store your list's url, name, and column names? A built-in UI sometime could be a problem...anybody with access can change the data, and people can accidently remove it and make you application crash.

  • Anonymous
    January 02, 2013
    Awesome, thanks for sharing this. Always been a question of mine, and something I always leaned towards property bag or lists, depending on the need. Seeing persisted objects is interesting, looks easier than using the property bag;) Thanks again!

  • Anonymous
    January 03, 2013
    Hi guys, last year i developed a feature to store dataconnections within SharePoint CA: SharePoint 2010 Data Connection Manager spugptwakeymanager.codeplex.com is at Codeplex, hope it helps

  • Anonymous
    April 27, 2013
    Well first, you are completely wrong about web.config. With SPWebConfigModification, everything is backed by SQL Server and changes are made instantly across the farm. Advocating editing by notepad is preposterous.

  • Anonymous
    May 08, 2013
    Harold, I don't think SPWebConfigModification class can store configuration changes to content or config databases (please correct me if I am wrong). It is just a convenient way to change web.config on all WFEs (implemented by a timer job behind the scene). However, you must still write some code to call the class and implement the changes to web.config, usually by a console app or an application page. And since you are doing that anyway, why not use property bags or Hierarchical Object Store, because they are stored in databases. Also, remember whenever you change web.config you recycle the application pool, and that could be a BIG problem for production. Zewei

  • Anonymous
    January 26, 2014
    Great article and concise summation! I'll definitely be referencing it in the future. There's one primary reason why I'd hesitate to use the hierarchical object store, and I'd be interested in hearing your opinion on it. Microsoft does not support a restore of the config database in any situation (except if you are replicating all of your SP servers and databases in a SAN consistency group using VSS). I've been reading up on configuration-only backups, but I haven't seen anything to say whether or not the hierarchical object store is included in that. Besides, I doubt many folks are including that in their DR plans. So, all that being said, I hesitate to use the hierarchical data store because of the DR ramifications. I have no confidence that I'll be able to recover those settings. And when you're in a true DR scenario, there's probably not going to be a lot of thought around the nuances of that configuration store. So, my inclination is to use lists for configuration since you'll have everything you need after a content database restore. The lists would need to be locked down with read-only permissions for regular users. The place to store location/connectivity data would be in the property bag. SharePoint Designer can be used to administer these values (click Site Options in the ribbon). So these two things combined could provide a fairly nice solution. To improve performance, add configuration settings to the cache to reduce the need to go back to the content database. A standardized helper class or assembly can be used to make this easy for developers, too. And if you need to store sensitive data that should be encrypted, use the Secure Store Service (again, have a helper class). I've done this successfully to hold a password for an encryption key to create a custom field type that encrypts its values. Anyway, those are my concerns around the hierarchical object store. I'd be interested in hearing your thoughts. Thanks! Keep up the great work!

  • Anonymous
    April 24, 2014
    As per this article, Values in the SPFarm property bag are stored in this Configuration database. May be the other property bag values are stored in content database.

  • Anonymous
    April 24, 2014
    Missed the link msdn.microsoft.com/.../ff650495.aspx