Six ways to store settings in SharePoint
When developing applications or custom solutions for SharePoint you will on several occasions have to store settings for you application of some kind. When developing database driven or other custom solutions you easily create a database table or make the settings in app/web.config file. You can of course use these approaches when developing for SharePoint, but there are some things to consider when doing this. This post will outline some approaches you can use to store your settings.
What I mean with application or solution settings is some kind of settings that you need for you application to work, such as a Url to a web service or a username and password. These settings are normally only editable by administrators, which requires you to have some security plans, and you need an interface to edit the settings.
Worth to have in mind is that SharePoint can span multiple servers and web applications, it also has the Site Collection and Site scopes which might need different settings if your application runs on several places.
Using a SharePoint List
Creating a database table for storing settings is not the best way in a SharePoint solution - you would use a SharePoint list for this instead. This is the easiest way. Creating a custom list with Title and a Value allows you to store all your settings in one place. There is no need to create a user interface, since you use out-of-the-box functionality and you can secure the list by using permissions on it. The drawback is you need some information (read other setting) that tells you where this list is located, so you're back on square one.
Using web.config
Using web.config is another way to store your settings. It's easy to store information in the appSettings element using a key/value combo. The .NET Framework have built-in functionality to read these settings and SharePoint has some (not so good working) features to deploy the settings in your farm with the SPWebConfigModification class. This approach can only be applied if your settings are web-application wide and you either deploy the settings with the SharePoint object model, which can be quite cumbersome, or manually edit the web.config file on all WFE's.
Using the SPWeb object
The SPWeb object has a Properties property that is persistable StringDictionary stored on the Site (SPWeb) level. This is a perfect solution when you have to store Site specific settings and have the setting available over all your farm. The Properties property is used like this:
1: SPWeb web = ...;
2: // set the value
3: web.Properties["TheSetting"] = "the value";
4: // update the value
5: web.Properties.Update();
6: // get the value
7: string val = web.Properties["TheSetting"];
Easy and simple when you have to store key/value combinations, but not so good when you have to store more complex objects, then you have to make some Xml serialization/deseralization yourself.
The permissions in this case is controlled by the MangedWeb permission and you have to build your custom interface.
Using the SPSite object
The SPSite object does not have any Properties property like the SPWeb object, so if you have to store your settings on the Site Collection level you just use the SPSite.RootWeb SPWeb object and use the approach above.
Using SPWebApplication Properties
If you need to store your settings on the Web Application level and you don't to make changes to the web.config, then you can use the SPWebApplication object. The SPWebApplication object inherits from the SPPersistedObject which has a Properties property. This property is a HashTable so you can store key/value combos here. The value can be of any type, as long as it can be serialized.
1: SPWebApplication webApp = ...
2: object obj = ...
3: // set value
4: webApp.Add("TheSetting", obj);
5: // persist it
6: webApp.Update();
This approach requires the user to be farm administrator and you have to build your own interface.
Using custom SPPersistedObjects
Perhaps the best (imho) way to store settings for your web application is to use custom SPPersistedObjects. This approach is very handy when you have to store multiple settings and more complex values. You create your own class that derives from the SPPersistedObject and add your settings as properties to the class and marks them with the Persisted attribute.
1: public class TheSettings: SPPersistedObject {
2: public TheSettings() {}
3:
4: public TheSettings(string name, SPPersistedObject parent, Guid id)
5: : base(name, parent, id) { }
6:
7: [Persisted]
8: public string WebServiceUrl;
9: }
Then you use the SPWebApplication GetChild method to retrieve your settings.
1: TheSettings settigs = webApplication
2: .GetChild<TheSettings>("theSettings");
I usually add two static methods to my settings class for easy creating and retrieval of settings:
1: public static TheSettings GetSettings(SPWebApplication webApplication) {
2: TheSettings settings = webApplication.GetChild<TheSettings>("theSettings");
3: if(settings == null) {
4: return TheSettings.CreateNew(webApplication);
5: }
6: return settings;
7: }
8: public static TheSettings CreateNew(SPWebApplication webApplication) {
9: return new TheSettings("theSettings", webApplication, Guid.NewGuid());
10: }
This also requires farm administrator to persist and you have to create an interface
