The release of SharePoint 2010 introduced a new way to develop and deploy SharePoint customizations called "Sandbox Solutions.” Sandbox solutions encompass both a new deployment model for no-code elements like master pages and page layouts, and a new least-privilege code execution environment.

Sandbox solutions have gotten a bad rap in some circles, largely related to the restrictions placed on developers, and the limitations on supported customizations. However, sandbox solutions offer some compelling features for developers and administrators that make them essential knowledge for anyone developing and deploying custom solutions for SharePoint 2010.

Safe Execution

Most customizations in SharePoint 2007 were deployed and executed in what is referred to as full-trust solutions. Code deployed as part of a full-trust solution executes with no code security or performance restrictions. A key concern for SharePoint administrators is the potential for custom code deployed in full-trust solutions to negatively impact the performance or the correct functioning of site across an entire farm.

Custom code deployed as part of a sandbox solution executes in a new service called the User Code Host. This service is responsible for accepting and managing a pool of worker processes that can execute code with highly restrictive code access security policy. Sandbox solutions are also limited to a subset of the SharePoint object model, and execute under the security permissions of the user who initiated the request.

With the protection offered by sandbox solutions, SharePoint administrators should feel comfortable allowing sandbox solutions to be deployed in their environment.

Isolated Deployment

It is not uncommon when developing custom solutions for SharePoint that customizations are intended for a specific site collection or site. An example might be the custom branding for a corporate intranet. Features deployed as part of full-trust solutions do not provide any ability to target a specific site collection, so developers often resort to hiding features to remove them from activation on sites they were not intended for.

Although the development of features and the packaging of sandbox solutions are very similar to full-trust solutions, sandbox solutions are uploaded and activated within a single site collection, in a special library called the Solution Gallery. This enables developers to work directly with business users to develop customizations. Deployment can be done by any user with Site Collection Administrator privileges, bypassing the requirement for Farm Administrator level permissions necessary when deploying full-trust solutions.

Once activated, site and web scoped features are available for activation, but will only be available within that site collection. Deployment isolation can make it easier to track and manage customizations, and also offers advantages when deploying new versions of customizations.

Resource Measurement and Quotas

Sandbox solutions provides both per-request and per-day resource usage restrictions. Per-request restrictions limit resource usage on a single request to execute sandbox code. An example is the default 30 second limit on the duration of a single request. Per-day restrictions limit usage against a daily quota assigned to each site collection by an administrator.

Daily resources usage is measured across 15 resource categories including CPU, memory, data queries and exceptions. Resource usage is aggregated and calculated into a point system. When the number of resource points used in a single day exceeds the site collection quota, all sandbox solutions are terminated. Daily quotas are reset every 24 hours.

Resource quotas act as a guardrail against runaway or poorly executing custom code, and give administrators confidence those sandbox solutions deployed at the site collection level won’t exhaust server resources that can impact the entire farm, and can help developers identify customizations that may need optimization.

Easier Upgrades and Migrations

Often one of the biggest challenges encountered during SharePoint upgrades and migrations is directly related to customizations. Full-trust custom solutions leave a large footprint on a SharePoint installation, introducing dependencies between resources installed locally on servers, and content and configuration stored in SQL databases. Before migrating or upgrading a content database, an inventory of all customizations must be made, and steps taken to either remove customizations, or migrate and pre-install the customizations prior to the content database. The effort can be error-prone, tedious and time consuming.

Sandbox solutions are deployed directly to site collections, and are stored in the associated content database. This allows a content database to be detached and moved across SharePoint farms safe as part of migrations or upgrades in the knowledge that all content and customizations are fully contained within the database.

Cloud Friendly

Office 365 is a collaboration and communication cloud service offering Exchange, Lync and SharePoint 2010, which are hosted online in Microsoft’s data centers. SharePoint Online leverages multi-tenancy features introduced in SharePoint 2010, providing access to enterprise features at a cost well below a dedicated hosted solution. Customers get a tenant administration screen that allows them to manage site collections, user profiles and other service configurations specific to their subscription, but does not permit access to farm-level settings or administration. Customers are not permitted to deploy farm-trust solutions.

In addition to being a safe and convenient deployment method for on-premise deployments, Sandbox solutions are also supported on Office 365, and are the only supported method for deploying server-side code that can execute within the hosted environment.

To Learn more on this topic and more, attend the SharePoint Saturday conference in Washington August 11-13th.  Chris is presenting the topics:

Editor's Note: You may also be interested in reading: