Using the SharePoint Logger from Sandboxed Code

Typical Goals

In many cases, you may want to give your sandboxed solution developers the ability to use the SharePoint Logger from within sandboxed code. However, the SharePoint logging framework relies on APIs that are not available within the sandbox.

Solution

The SharePoint Logger includes a full-trust proxy that makes logging and tracing functionality available to sandboxed code. After you install and register the logging proxy, the SharePoint Logger automatically uses the proxy when it detects that it is running in the sandbox environment. As a result, the developer can use the SharePoint Logger in the same way regardless of whether he or she is writing full-trust code or sandboxed code—the developer experience is unchanged. If a developer attempts to use the SharePoint Logger in the sandbox environment, and the proxy is not installed and registered, any log or trace messages are dropped.

To install the logger proxy assemblies and register the proxy operations, you will need to deploy the solution package provided in Microsoft.Practices.SharePoint.Common.LoggerProxy. This package deploys a farm-scoped feature with a feature receiver class that registers the proxy operations. After it is deployed, the logger will function in the sandbox. Because the logger proxy is deployed at the farm scope, the proxy operations are available to all site collections within the farm.

Note

If your code will log or trace within the sandbox environment, and you want to specify a severity level, you must use the method overloads that accept SandboxEventSeverity and SandboxTraceSeverity values, respectively, because the EventSeverity and TraceSeverity enumerations are not available within the sandbox. You can also use any logging or tracing operation that does not specify a severity level. Any code that uses SandboxEventSeverity or SandboxTraceSeverity values will work both within and outside the sandbox.

You cannot register diagnostic areas or categories from the sandbox environment, because areas and categories must be persisted to farm-level configuration settings. If you want to create diagnostic areas and categories for sandboxed solutions, you must create them from outside the sandbox environment.

You may not be able to install the full-trust proxy for logging to your environment. Another alternative is to implement your own custom logger and write the event and trace messages to an alternative location such as a list. The following code example shows the methods that you must override.

public class MyLogger : SharePointLogger
{
    protected override void WriteToOperationsLogSandbox(string message, 
                     int eventId, SandboxEventSeverity? severity, string category)
    {
        WriteToOperationList(message, eventId, severity, category);
    }
    protected override void  WriteToTraceSandbox(string message, 
                     int eventId, SandboxTraceSeverity? severity, string category)
    {
        WriteToTraceList(message, eventId, severity, category);
    }
}

You should then register your logger with the Service Locator in a site-scoped feature receiver.

ServiceLocatorConfig cfg = new ServiceLocatorConfig();
cfg.Site = SPContext.Current.Site;
cfg.RegisterTypeMapping<ILogger, MyLogger>();

Users need to have access to the lists to which the messages are written because the messages are logged from the context of the accessing user.