SharePoint Stream

A wide-ranging SharePoint study guide focused to IT Consultants

Define application configuration approach

This objective may include but is not limited to: defining “web.config” modifications, Lists as a configuration option, Property bags, declarative vs. programmatic, SP persisted objects

Defining “web.config” modifications

Web.config modifications are made on some different situations across a SharePoint system development. Maybe there’s a need to configure FBA authentication, customizing the Session State, registering an HTTPModule, or you need to add some trusted code to run in your server, or you want to create keys so you can reference them latter on the server-code. No matter what your goal is with modifying web.config files on the WFE server, you can accomplish it using a feature that will tweak all the we.config files from all your WFE servers at once.

That can be succeed  by access the SPWebApplication object of your SP system on the FeatureActivated operation and finally by just adding a SPWebConfigModification object to your web application through the WebConfigModifications.Add operation.

Here’s a sample:

   1: public  override  void  FeatureActivated(SPFeatureReceiverProperties  properties)

   2: {

   3:     var  spWebApplication = (SPWebApplication) properties.Feature.Parent;


   5:     if(webApp != null){


   7:         string value = "FG33D-1G121-1121-24324-FR32";


   9:         var  mySetting = new  SPWebConfigModification 

  10:         {

  11:             Name = string.Format("add [@key='listID'] [@value='{0}']", value),            

  12:             Path = "configuration/appSettings",

  13:             Sequence = 0,

  14:             Owner = "pedroharp",

  15:             Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode,

  16:             Value = string.Format("<add key='listID' value='{0}' />", value)

  17:         };


  19:         spWebApplication.WebConfigModifications.Add(mySetting);

  20:         spWebApplication.Update();

  21:         spWebApplication.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

  22:     }

  23: }

Good references can also be exploited here and here.

Lists as a configuration option

A key capability of SharePoint is the ability to store and manage arbitrary data. For this reason, SharePoint lists provide many capabilities that are ideal for storing configuration setting values. From a developer’s point of view, one strong benefit of this option is that it is likely consistent with other actions being performed in the course of custom development so no new knowledge is needed; reading and writing SPListItem objects are common activities for SharePoint developers.

While storing configuration settings in a SharePoint list does have some drawbacks, it is the most full-featured option and the only one that offers all of the advanced features – versioning, approvals, workflow support, recycle bin, and so on, without requiring significant custom code.

The biggest drawback is that this option requires the creation of a list in which to store values. This, in turn, could require the creation of a Site Collection and/or Site, if the list will not be in an existing Site. However, it is unlikely that this presents a significant obstacle to most SharePoint applications.

Property bags

It makes sense to store settings for small, simple, global values which do not change often or at all.

Examples would include server names or URLs, list names, and other similar items which might typically be configured after when the application is deployed and then never changed. Potentially, too, these items might be read often as part of the processing of your application code. These all take advantage of the fact that web.config entries are stored in memory when the application starts up (leading to increased performance for repetitive use) and avoid the drawbacks by not changing often.

Many of the important SharePoint objects support a Properties property:

  • SPContentDatabase
  • SPFarm
  • SPServer
  • SPWebApplication
  • SPWeb
  • SPFolder
  • SPListItem
  • SPFile
  • This property returns a property bag object, which is a collection of key/value pairs. Each key must be uniquely named, each value is a string, and the key/value pair is stored with the owning object in the proper content database. The string value could be a serialized representation of a more complex object if that is required. There are a few important SharePoint objects which do NOT support a property bag – namely SPSite, SPList and SPUser. For two of these objects a property bag on a child object is available:

  • For SPSite, use SPSite.RootWeb.Properties to make use of the property bag of the root Web of the site collection
  • For SPList, use SPList.RootFolder.Properties to use the property bag of the root folder of the List. It is also important to note thatSPDocumentLibrary does not expose a property bag. Instead, the document library should be cast as an SPList and then used as above.
  • There is one additional consideration when working with an SPWeb object. In addition to the Properties property, , SPWeb also supports an AllPropertiesproperty, which is a hashtable. Anything you add to Properties will automatically be added to AllProperties, but the reverse is not true. AllProperties is the recommended location to use when storing properties. It is important to keep in mind that this only applies to an SPWeb.

    For storing configuration settings, the property bag is the first truly workable option. It gives you the ability to store arbitrary key/value pairs that are scoped at a very specific level.

    SP persisted objects

    The last option is a SharePoint construct known as the hierarchical object store. There is no functional difference between the hierarchical object storage and a property bag that is scoped at the SPFarm level, so deciding which to choose is largely a matter of preference. Like property bags, hierarchical object storage is a native capability of SharePoint that is available as soon as a SharePoint server farm is built and is available for the entire life of that farm. This means that any application can interact with the hierarchical object storage without needing to know anything else about the environment. Using the hierarchical object storage is bit more complicated as it requires the creation of a custom object which inherits from SPPersistedObject. Nonetheless, the hierarchical object storage is a valid tool and can be useful in your applications.

    More about this issue on here.

    About these ads

    One response to “Define application configuration approach

    1. Pingback: Study guide to the exam 70-576: Microsoft SharePoint 2010 Designing and Developing « SharePoint Stream

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s


    Get every new post delivered to your Inbox.

    %d bloggers like this: