A Brief Look at Sandboxed Solution Restrictions

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.