SharePoint Deployment Models

SharePoint solutions are generally not installed by using MSI or ClickOnce technology. (Some exceptions are noted later.) SharePoint has its own installation system. Instead of MSI files, the solutions are packaged in SharePoint solution package files. These are CAB files that have a special extension: .wsp. SharePoint solution package files can contain several kinds of elements, including assemblies, user controls, custom ASP.NET pages, XML configuration files, resource files, images, list definitions, Web Parts, Features, and others. JavaScript files and Silverlight .xap files can also be deployed to the servers by using SharePoint Solution Packages.
There are two kinds of solutions in SharePoint: farm solutions and sandboxed solutions. The differences between them are discussed in this section and in Worker Processes, Farm Solutions, and Sandboxed Solutions later in this article.

Note

The terms "solution" and "feature" are familiar in software development. The first thing to note about the SharePoint deployment model is that these terms are names of formal components of SharePoint that are defined in this section. By convention, "Feature" is capitalized when it refers to the SharePoint component of that name. Throughout this article, I will follow the additional convention of italicizing "farm solution," "sandboxed solution," and "solution" when the SharePoint component is being referenced. When either "solution" or "feature" is lowercase and not italic, it is being used in its ordinary sense.

Installation of a SharePoint solution package is a multi-step process:

1. Adding: A solution package file is added to one of two stores.
   
   • Farm solutions are deployed by farm administrators to the farm's solution store, which is in the farm's configuration database. This is done by using either the SharePoint Management Shell or the object model.
     
   • Sandboxed solutions are deployed to a specific site collection's Solution Gallery by a site collection administrator. The gallery is a special SharePoint list, so it is in the content database. Solution deployment to the gallery is done through the Site Actions UI of the site collection or by using SharePoint Management Shell. For information about the difference between site collections and websites, see Middle Level Object Model later in this article.
     
   Thus, SharePoint Solution Package files are never installed to the file system of any server, although elements of a farm solution may be installed to the file system when the solution is deployed.
   
2. Deploying: The solution package is unpacked and its elements are deployed to their appropriate places.
   
   • For a farm solution, this step also requires a farm administrator and can be done by using either Central Administration or SharePoint Management Shell, or the object model. Some examples of how elements are deployed: user control files (.ascx) are copied to %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\ControlTemplates and assemblies are deployed to the global assembly cache or to a web application's \bin folder. If there are SharePoint Features (defined later) in the farm solution, they are in this step copied to a subfolder of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES.
     
   • For sandboxed solutions, the deployment step is taken by a site collection administrator. There are limits on what kinds of elements can be in sandboxed solutions and where they can be deployed. For example, nothing can be deployed to the file system of the servers from a sandboxed solution. Features in sandboxed solutions are deployed to the content database.
     
   It is also in this second step that any Features in the solution are installed in the Feature Gallery of the farm, web application, site collection, or website, depending on the scope of the Feature. (For more information about the relations of farm, web applications, site collections, and websites to one another, see Content Hierarchy later in this article.)
   

Within a SharePoint solution package, there can be an additional level of encapsulation because a solution can have one or more SharePoint Features. A Feature can be installed at the scope of the farm, the web application, the site collection, or the website. After it is installed, a Feature must be activated by owners of any website within the scope; so Activating becomes a third step of installation for Features. Features can contain content types, controls, custom actions, custom fields, files, workflows, list instances, list templates, event receivers, and document converters; although some of these cannot be included in certain scopes. (Features that are deployed in sandboxed solutions can be scoped only to a site collection or website. For site collection-scoped features in sandboxed solutions, the second and third steps are combined. The Features are activated when the solution is deployed.)

Note

SharePoint is not consistent in its terminology with regard to installation. The terms adding, deploying, and activating are the most frequently used to refer to the three steps of installation; but depending on what tool is used to complete a step and whether the solution is farm or sandboxed, you will see a variety of terminology. The first step may be called adding, installing, or uploading. The second step may be called deploying, activating or installing. There is a similar inconsistency in the terms for reversing these steps; but most commonly, reversing the second step is called retracting and reversing the first step is called removing. The third step, which applies only to Features, is always called activating, and its reversal is always called deactivating.

Some SharePoint solutions target one of the client object models, either exclusively or in addition to targeting the server object model: the JavaScript, Silverlight, and Microsoft .NET Framework client object models. (For more information about the client object models, see Client Object Models in SharePoint later in this article.) There is nothing unusual about the installation of the client portion of such solutions.

• The script files that define the JavaScript object model are downloaded to a client computer when a page that references them is opened.
  
• Similarly, a Silverlight .xap executable is downloaded to the client computer when a page that is hosting it is accessed. The SharePoint assemblies that contain the Silverlight client object model are encased in the .xap file. Those assemblies are Microsoft.SharePoint.Client.Silverlight.dll and Microsoft.SharePoint.Client.Silverlight.Runtime.dll. (It is also possible to cache these assemblies on the front-end web server. For details, see RIA Technologies: Benefits, Tradeoffs, and Considerations.)
  
• Stand-alone .NET Framework applications (such as a WPF application) that target the SharePoint client object model are installed just as any other client applications: using MSI files or ClickOnce. The assemblies that contain this client object model, Microsoft.SharePoint.Client.dll and Microsoft.SharePoint.Client.Runtime.dll, must be distributed as part of the solution. The redistributable is located at SharePoint Foundation 2010 Client Object Model Redistributable.
  

For more information about the processing of client-side logic in SharePoint, see Client Application Models in SharePoint 2010.
For more information about the deployment system, see Building Block: Features, Building Block: Solutions, and Packaging and Deployment in SharePoint Foundation.