This is a quick post with a message that may seem obvious, but I’ve seen plenty of code that makes me think maybe it isn’t. So here’s my suggestion: store your application configuration such that it matches the scope of your SharePoint feature.
To elaborate, I’ve mentioned before that SharePoint developers who come from a custom .NET development background are generally inclined to put application configuration settings in the web.config – which works fine for some things. However, what if you have a setting that needs to differ by site collection and you have many site collections in your web application? You could certainly create a site collection-specific AppSettings key for each site collection in your web.config, but that seems messy to me.
Here are my suggestions for where you should think about storing your configuration information, based on the scope of your feature:
| Feature Scope | Configuration |
| Farm |
|
| Web Application |
|
| Site Collection (SPSite) |
|
| Site (SPWeb) |
|
The references to SPConfigStore here refer to this CodePlex project submitted by Chris O’Brien. Note that items in the store are grouped by “Category,” so use of the SPConfigStore approach requires some thought about naming conventions and how the categories will be assigned.
The code below shows an example of the use of the Properties collection on an SPWeb:
1: /// <summary>
2: /// Returns a property value stored in an <see cref="SPWeb" /> instance
3: /// </summary>
4: /// <param name="web"></param>
5: /// <param name="name">the name of the property to retrieve</param>
6: /// <returns>the value for the property; empty string if property doesn't exist</returns>
7: private static string GetWebSetting(SPWeb web, string name)
8: {
9: if (web.Properties.ContainsKey(name))
10: {
11: return (string)web.Proper ties[name];
12: }
13: else
14: {
15: return string.Empty;
16: }
17: }
Next time you fill out the “Scope” attribute of your feature.xml, make sure your plan for configuration management matches your application.
