Archives
-
Is your code running in a SharePoint Sandbox?
You could execute a function call that is not allowed in the sandbox (for example call a static method on SPSecurity) and catch the exception. A better approach is to test the friendly name of you app domain:
AppDomain.CurrentDomain.FriendlyName returns "Sandboxed Code Execution Partially Trusted Asp.net AppDomain"
Because you can never be sure that this string changes in the future, a safer approach will be:
AppDomain.CurrentDomain.FriendlyName.Contains("Sandbox")
See http://www.sharepointoverflow.com/questions/2051/how-to-check-if-code-is-running-as-sandboxed-solution for a discussion on this topic.
-
Logging to SharePoint 2010 ULS log from sandbox
You can’t log directly from sandbox code to the SharePoint ULS log. Developing code without any form of logging is out of this time, so you need approaches for the two situations you can end up with when developing sandbox code:
You don’t have control over the server (BPOS scenario):
- You can log to comments in your HTML code, I know it’s terrible, don’t log sensitive information
- Write entries to a SharePoint “log” list (also take care of some form of clean up, for example if list longer that 1000 items, remove oldest item when writing new log message)
You have control over the server:
- You can develop a full-trust sandbox proxy (http://msdn.microsoft.com/en-us/library/ff798427.aspx) that provides you with functionality to do logging. Scot Hillier also provides a ready made WSP package containing such a proxy that must be deployed at farm level (http://sandbox.codeplex.com, SharePoint Logger)