Partager via

Understanding SharePoint Execution Models

  • Article

In earlier versions of SharePoint, there were limited options for deploying custom solutions to a SharePoint environment. You would deploy assemblies either to the global assembly cache or to the Web application's bin folder within the Internet Information Services (IIS) file structure. You would deploy other resources, such as images, configuration files, user controls, and SharePoint features, to the SharePoint file structure (commonly referred to as the "SharePoint root") on each server. In order to manage the installation, deployment, and retraction of these assemblies and resources over multiple servers, you would use a SharePoint solution package (WSP). The solution package would have to be placed on a file system available to a SharePoint server in the farm, installed using the stsadm command line tool, and then deployed to one or more Web applications from either the command line or the SharePoint Central Administration Web site.

This approach works well, as long as you meet the following criteria:

  • You have server-side access to the SharePoint farm.
  • You are a member of the Farm Administrators group.
  • You have the confidence of the IT team.

This is increasingly unlikely to be the case. Many large companies provide a single, centrally-managed SharePoint platform and simply provision site collections for disparate divisions, departments, and teams as required. Many smaller companies look to hosting companies to provide a SharePoint environment, which is also typically provided on a per-site collection basis. In both cases, developers who are looking to provide custom solutions are unlikely to have the server-side access they need to deploy their solutions. Hosting companies in particular may be understandably reluctant to permit anyone to deploy code that may jeopardize the performance, stability, or security of the SharePoint farm and, therefore, their other tenants.

In response to the market need to allow developers to create code that can be run in shared environments, SharePoint 2010 supports an additional deployment and execution model: the sandboxed solution. This model allows users who do not have access to the server file system to deploy managed code applications into individual site collections. Sandboxed solutions are deployed using a SharePoint solution package to a specialized gallery (document library) in the root site of the site collection.

These applications run in an environment of reduced trust—the sandbox—and are executed within an isolated process that uses a low-trust account. When you develop solutions that target the sandbox execution model, you are restricted to using a subset of the SharePoint APIs and your code must observe more stringent code access security policies for the rest of the .NET Framework base class libraries. These constraints offer additional safeguards to the IT team, because the inherently lower trust environment reduces the risk of a security exploit by the sandboxed application. In return, the sandbox execution model offers developers the opportunity to customize and extend the functionality of their SharePoint sites in circumstances where the deployment of custom code would otherwise be prohibited, such as hosted solutions or large, regulated corporate deployments.

In order to balance this newfound freedom to deploy managed code without the involvement of the IT team, SharePoint 2010 includes various safeguards against inefficient or resource intensive sandboxed applications. In addition to the restrictions on the APIs that are available to the developer, the sandboxed solution framework monitors the execution of sandboxed applications and can terminate code that runs for too long or consumes too many resources. This contributes to the overall stability of the system. Administrators may configure a points-based system to throttle the system resources that are made available to sandboxed applications.

This section provides an overview of each execution model, from the familiar full-trust approach to the new sandbox option. It identifies the benefits and drawbacks of each approach, and it examines when it is appropriate to use a particular model. The remainder of the chapter then provides a detailed technical insight into the workings of each execution model.

Note

This documentation focuses on server-side execution models. You can also interact with a SharePoint environment from client platforms such as Silverlight or Windows Presentation Foundation (WPF) through the new SharePoint client object model. For more information about the client object model, see Client Application Models.