As stated earlier, only a restricted subset of the SharePoint object model is available to sandboxed solutions. These restrictions reduce the risk of badly written custom code from destabilizing the farm. The allowed subset of the object model includes
• Microsoft.SharePoint
namespace, except SPSite
constructor, SPSecurity
object, SPWorkItem
and SPWorkItemCollection
, SPAlertCollection.Add
, SPAlertTemplateCollection.Add
, SPUserSolution
and SPUserSolutionCollection
, and SPTransformUtilities
• Microsoft.SharePoint.Navigation
namespace
• Microsoft.SharePoint.Utilities
namespace, except SPUtility.SendEmail
and SPUtility.GetNTFullNameandEmailFromLogin
• Microsoft.SharePoint.Workflow
namespace
• Microsoft.SharePoint.WebPartPages
namespace, except SPWebPartManager
, SPWebPartConnection
, WebPartZone
, WebPartPage
, ToolPane
, and ToolPart
To aid you in sandboxed solution development, Visual Studio trims the IntelliSense and does not list the objects and methods not supported in sandboxed solutions.
Apart from the preceding restrictions, code access security (CAS) imposes the following additional restrictions on sandboxed solutions:
• Calls to managed code are not allowed.
• Access to databases is not allowed.
• Read and write operations to file system are not allowed.
• No access to reflection APIs.
• No access to registry.
• Only those assemblies of .NET 3.5 Framework that have the AllowPartiallyTrustedCallersAttribute
attribute set to true can be called from sandboxed solutions.
The policy is defined in the wss_usercode.config file present at 14CONFIG location. You should abstain from editing this file, since any modifications to this file are not supported by Microsoft.