Registering the SharePoint Logger

Feb 23, 2010 at 12:34 AM

I am trying to use the Configuration Manager in a 2010 project.

This is the code I am using in the FeatureActivated override of a Feature Receiver:

IConfigManager configManager = SharePointServiceLocator.Current.GetInstance<IConfigManager>();
if (configManager != null)
    configManager.SetInPropertyBag("DBConnection", @"somestring",

When I call this from a Feature Receiver, I get an Access Denied error from the line:

WriteToTraceLog(propertyBag, key, valueAsString);

in HierarchicalConfig.SetInPropertyBag.

Reading the documentation, I see I have to register the SharePoint Logger as a Farm Feature, but the documentation doesn't say how.

I am using Drop 3.


Any ideas?




Feb 23, 2010 at 12:48 AM


Is this from a sandboxed solution?  The logger reads from the farm which will cause an exception in the sandbox.  We are working on a sandbox proxy to address this.


Feb 23, 2010 at 12:53 AM

No, it's not a sandboxed solution.

I also created a Farm-level Feature receiver and on activate made the call to DiagnosticsService.Register() to see if this would help, but I am still getting the access denied error on the WriteToTraceLog line.



Feb 23, 2010 at 1:50 AM

I think I know what is going on.  By default the logger registers itself, so you don't actually need to call register.  I think the security exception you are seeing is because the event source is not created for the default event in the event log.  Which version of SharePoint are you running, the beta or the RC?

Feb 23, 2010 at 1:55 AM

The RC - 4730.1000


Feb 23, 2010 at 2:26 AM

That is probably it then, this behavior changed between beta and RC.  We will have a better solution for this in two weeks.  Try registering the following event source and see if the problem goes away: 

Patterns and Practices



Feb 23, 2010 at 2:39 AM

Unfortunately that didn't help. I registered the event source as follows:

EventLog.CreateEventSource("Patterns and Practices", "Application");

But I still get the same error.

Feb 23, 2010 at 3:14 AM

hmm. Can you try doing this logic in feature installed instead of feature activated and see if it works?  You have a higher permission level.

Apr 20, 2012 at 3:11 AM

Well I had the same issue. Got it resolved by specifying AllowUnsafeUpdates as true just before calling the SetInPropertyBag(). Of course the property needs to be set back to "false" after the method invocation.

Hope this helps!