Build farm solutions in SharePoint 2013
Published: July 16, 2012
Get an overview of our documentation about developing, packaging, and deploying administrative extensions to SharePoint 2013 using farm solutions.
Applies to: SharePoint Foundation 2013 | SharePoint Server 2013
SharePoint 2013 has its own system for installing extensions to SharePoint administrative functions that is different from other Windows applications and platforms. No MSI file or ClickOnce technology is involved. Instead, the assemblies, XML, and other files in the extension are bundled into a single file, which is called a solution package. A solution package has a .cab-based format but a .wsp file extension. The package can contain SharePoint Features and all their child components as well as certain kinds of components that are not deployed in Features. Farm administrators upload the packages to a farm-wide storage location from where they can be deployed and their Features activated.
Unlike apps for SharePoint, farm solutions contain code that is deployed to the SharePoint servers and makes calls to SharePoint's server object model. These assemblies always run with full trust. Moreover, the Features in farm solutions can have scope as wide as the site collection, web application, or whole farm, in addition to the website scope of Features in apps for SharePoint. These aspects of farm solutions sometimes make farm administrators reluctant to install them, unless they come from a well-known and trusted source. For this reason, SharePoint extensions that are primarily for use by end users should be developed as apps for SharePoint, not farm solutions. Farm solutions should be used for customizations of SharePoint administrative functions, such as custom timer jobs, custom Windows PowerShell cmdlets, and extensions of Central Administration. For more on the advantages of apps for SharePoint and the uses of farm solutions, see Apps for SharePoint compared with SharePoint solutions.
Development of farm solutions has not changed since SharePoint 2010, so this section contains links into the SharePoint 2010 SDK. To avoid confusion, keep the following points in mind at all times when using the SharePoint 2010 SDK to develop against SharePoint 2013:
You will see many references to "sandboxed solutions" in the SharePoint 2010 SDK. Sandboxed solutions are deprecated in SharePoint 2013.
Our recommendation that farm solutions be used primarily for administrative extensions did not apply in SharePoint 2010. Therefore, many of the samples and other documentation in the SharePoint 2010 SDK may be about end-user extensions that are deployed as farm solutions.
The terms "server-side" or "server code" in the SharePoint 2010 SDK refer to code that calls the SharePoint server object model. These terms do not refer to code that runs on remote web servers (that is, web servers external to the SharePoint farm). Code that calls SharePoint from remote web servers, in both SharePoint 2010 and SharePoint 2013, always uses one of the SharePoint client object models. In the SharePoint 2010 SDK, such code would be called "client-side" or "client code."
The assemblies in a farm solution in SharePoint 2010 could be deployed with Custom Access Security (CAS) policies. Such policies are ignored in SharePoint 2013; all assemblies in farm solutions in SharePoint 2013 run with full trust.
Packaging and deployment
The basics of packaging, installing, updating, and localizing farm solutions are explained in Solutions Overview and the node Farm Solutions in SharePoint 2010. Development of particular SharePoint components for inclusion in a farm solution is explained in the relevant nodes of SharePoint 2010 SDK. Most of the components in a farm solution should be encapsulated in one or more custom SharePoint Features. For information about designing and creating Features, see the Using Features in SharePoint Foundation node of the SharePoint 2010 SDK.
Guidance about extending the administrative functions in a SharePoint farm is in the SharePoint Foundation Administration node of the SharePoint 2010 SDK. There you can find explanations about extending Central Administration, creating custom Windows PowerShell cmdlets, customizing upgrades and migration, customizing backups, and customizing SharePoint event logging. One section explains how to customize the SharePoint farm health and performance measuring system. For instructions about creating a custom timer job, see How to: Run Code on All Web Servers.
July 16, 2012