Sandboxed Solutions in SharePoint 2010

In this article I am describing one of the new features of SharePoint 2010; it is named Sandboxed Solutions. One of the biggest problems with SharePoint 2007 development is that all of its solutions run with full trust. This makes SharePoint administrators hesitant to publish any solution that may disturb the stability of the SharePoint farm.
Sandboxed Solutions, new in SharePoint 2010, address this by allowing site collection administrators to deploy solutions that are safe to run. In the SharePoint 2007 environment, many companies feel they need to separate even their normal business process data from custom applications developed using SharePoint as an access mechanism, by placing these applications under a separate application pool and thus preventing development changes from affecting the server. This concern was primarily due to the unstable nature of custom-developed solutions, especially early in the development and testing phases. The Sandboxed Solution is effectively a process separation engine, designed to allow code within the sandbox to run in a separate worker process thread, thereby moderating the concern that an overly busy application pool will interfere with other normal operations.
Sandboxed solutions are restricted to running under a subset of the SharePoint API and the framework can monitor these solutions and shut down any risk that may affect the stability of the SharePoint farm. Sandboxed Solutions are aimed at creating business agility. This helps to satisfy the demanding nature of business by quickly creating and deploying solutions. Businesses can deploy these solutions rapidly because there's less risk and less need for a review process to slow them down. Site collection administrators can even deploy third-party solutions without fear of bringing down the entire farm. This feature was missing in SharePoint 2007. In 2007 version components are deployed by a farm administrator and are scoped to the farm level. Sandboxed Solutions are SharePoint Solution Package files that are limited in what they can do and in the server resources they can use. What they can do is limited using Process Isolation and Code Access Security limited to the SharePoint Site collection. The resources they can use are limited by process monitoring, logging and log aggregation. Any individual action is limited and the solution is also given a daily limit of resources. This provides for a complete isolation system that ensures code running in a sandboxed solution cannot reach out to access information beyond the scope of the deployment. Specifically, Sandboxed Solutions will not be able to make updates to the SharePoint object model beyond the scope of the SPSite object. Farm level and Web application level changes are allowed only for read operations.
Sandboxed solutions allow us to:

• Deploy custom developed or downloaded from the Internet
• Such custom code we deployed cannot threaten the stability of our farm
• Only a small number of project templates are available for sandboxing.
• Those projects which operate under the sandbox can only access data from the local Site collection.
• Sandbox solutions that need access to other forms of data must be run through a BCS Connector.

Some of the SharePoint item types supported by Sandbox Solutions are:

• List definitions
• List instances
• Content Types/Fields
• Navigatio
• Web Parts derived from Web Part
• Event receivers
• Custom Workflow Actions
• Workflows

Sandboxed solutions allow more custom code deployment flexibility by site collection owners, while at the same time putting up guards to protect the server. This is a very good feature compared to SharePoint 2007. The way developers interact with a sandboxed solution is similar to normal solutions, but somewhat more automated. An important concept to stress is the fact that solutions get validated before they are allowed to be installed, and that we can extend the validation. After installation the solution is activated, which auto-activates features. When deactivating a sandboxed solution, Web Parts from within the sandbox will no longer execute. If we re-activate the solution, the Web Parts will start executing again. We can change the behavior using feature receivers.

Monitoring Sandbox Solutions

Site Collection administrator can monitor resource usage of Sandboxed Solutions via Site Actionsà Site Settingsà Galleriesà Solutions. The simple dashboard shows how much resources have been consumed by deployed solutions.