Joel's SharePoint Architecture Blog

SharePoint Server, SharePoint Online and Office 365 Training, Architecture, Administration and Development

SPPersistedObject: Persisting Configuration Data in SharePoint 2010

by

Continuing in my series of articles showing the many ways in which we can store configuration data for your SharePoint applications, this time we look at how to use SPPersistedObject to achieve this.

Don’t forget to check out part 1 of the series in which we find out how SPWebConfigModification can be used for persisting application configuration in SharePoint 2010.

Persistence Using SPPersistedObject

SPPersistedObjects let you store hierarchical configuration data for your application in SharePoint. An SPPersistedObject is a class you subclass. You can then add fields (not properties) to your class, attribute them with [Persisted], and SharePoint will serialise the object to Xml in the SharePoint Configuration database.

Code Snippet
  1. [GuidAttribute(“8AC7737A-8A57-4DD9-A782-B0B3F4595884”)]
  2. public class JoelsConfigSettings : SPPersistedObject
  3. {
  4.     public JoelsConfigSettings()
  5.     {
  6.     }
  8.     public JoelsConfigSettings(string name, SPPersistedObject parent)
  9.         : base(name, parent)
  10.     {
  11.     }
  13.     public JoelsConfigSettings(string name, SPPersistedObject parent, Guid id)
  14.         : base(name, parent, id)
  15.     {
  16.     }
  18.     [Persisted]
  19.     public string Value1;
  21.     [Persisted]
  22.     public int Value2;
  23. }

The above code creates a class with two fields (string Value1 and int Value2) which can be persisted for the current Web Application with the following code:

Code Snippet
  1. SPSite s = SPContext.Current.Site;
  2. JoelsConfigSettings settings = new JoelsConfigSettings(“JoelsSettingsKey”, s.WebApplication, s.ID);
  3. settings.Value1 = “Joels Value 1”;
  4. settings.Value2 = 2;
  5. settings.Update();

We can later retrieve – and optionally delete – the settings by calling GetChild<> on the WebApplication object.

Code Snippet
  1. SPSite s = SPContext.Current.Site;
  2. JoelsConfigSettings settings = s.WebApplication.GetChild<JoelsConfigSettings>(“JoelsSettingsKey”);
  3. string value1 = settings.Value1;
  4. int value2 = settings.Value2;
  5. // optionally delete our settings
  6. settings.Delete();
  7. // but proper removal requires unprovisioning and uncaching too
  8. settings.Unprovision();
  9. settings.Uncache();

As an alternative to storing at the Web Application level, you can use a Farm object instead.

Advantages

You configuration data is stored in the SharePoint Configuration database. This means it will be backed up along with the rest of your SharePoint data – assuming you perform SharePoint backups, of course. Smile

Your data is also safe from prying eyes as there is no UI to edit these settings.

Disadvantages

There is no built in user interface to manage SPPersistedObjects. This is both a good and a bad thing: you have to provide your own way of editing the values you wish to store. To read and write these values you also need to impersonate a user, such as a Farm Administrator, with read and write privileges on the Config database (SPSecurity.RunWithElevatedPriviliges() won’t help here!). There are some reports of SPPersistedObject use corrupting the Hierarchical Object Store; it’s unclear whether this is due to incorrect usage or something more flaky. Reading the comments, one of our readers has suggested this corruption happens for them if they use obfuscated assemblies. (Many thanks, Joe!)

Proceed with caution, and thoroughly test your code first on a virtual, scratch, SharePoint farm.