Problems with the WebApplication ”property bag”

Jul 12, 2010 at 1:52 PM

Hi, I am using the latest 2010 production guidance, and have some challanges when getting and updating webapplication scoped settings in the ”property bag” from an simple WebPart. I copied the code from the documentation for getting an configuration setting:

IServiceLocator serviceLocator = SharePointServiceLocator.GetCurrent();
IHierarchicalConfig config = serviceLocator.GetInstance<IHierarchicalConfig>();
string workgroupName;
if (config.ContainsKey("Contoso.Applications.WorkgroupName"))
workgroupName = config.GetByKey<string>("Contoso.Applications.WorkgroupName");

When I insert this in a WebPart on a newly created webapplication I get an Access Denied from BaseUpdate() on SPPersistedObject:

Access denied.

   at Microsoft.SharePoint.Administration.SPPersistedObject.BaseUpdate()
   at Microsoft.Practices.SharePoint.Common.Configuration.WebAppSettingStore.Load(SPWebApplication webApp)

A solution to this problem might be implementing:

protected override bool HasAdditionalUpdateAccess()
return true;

on WebApplicationSettingStore?

Another thing that I wonder about is the settingStore.Update()-call in WebAppSettingStore.Load(). On some webapplications you might ”risk” calling update, even though your intention was just reading? Of course the update call could be implemented because of some concurrency issues, but everytime the store is updated in SPWebAppPropertyBag; a new instance of the store is fetched?


Jul 13, 2010 at 12:14 PM

Thanks for the feedback.  I've added a blog entry on writing application settings to the web app level and farm level for more clarity on the write behavior for farm and web app at  There is a security feature that prevents writing at these levels from a content web.  The blog describes the issue and the alternatives to managing these settings.

The only time there is an issue with writing to the web application on load (or farm...they both work this way) is when there have never been any settings stored to those levels within the environment.  This is by design.  I think it is a reasonable expectation that before any application is deployed that reads from these locations, something has been set at these locations somewhere in the environment.  There is a simple workaround fix if this is not the case to this which is write anything at the level in a feature installed at these levels before looking.

An alternative is to implement conditional logic in the store that will always return false on check and throw an exception when accessing a value if the persisted object did not exist.  We chose not do this as it complicates the code with conditional logic, and we believe this is an exceptional condition. 

I'm open to more feedback on the issue.  If this is tripping up a lot of people, we will look at implementing workaround logic for it.