Apps for SharePoint compared with SharePoint solutions
Published: July 16, 2012
Learn about when you should develop your SharePoint 2013 extension as an app for SharePoint and when you should develop it as a SharePoint farm solution.
Applies to: SharePoint Foundation 2013 | SharePoint Server 2013
SharePoint sandboxed solutions are deprecated in SharePoint 2013 in favor of developing apps for SharePoint, but sandboxed solutions can still be installed to site collections on SharePoint 2013. This topic compares apps for SharePoint with farm solutions. The latter are packages of SharePoint components that are uploaded to a farm-wide gallery from where they can be installed. For more information about the basics of farm solutions, see Solutions Overview and Farm Solutions in SharePoint 2010. For an overview of apps for SharePoint, see Apps for SharePoint overview.
The most important guidance we can give you is to develop an app for SharePoint rather than a classic solution whenever you can. Apps for SharePoint have the following advantages over classic solutions:
They provide users with the easiest discovery, purchase, and installation process.
They provide administrators with the safest SharePoint extensions.
They provide you with the simplest marketing and sales system based on a Microsoft-provided online app store.
They maximize your flexibility in developing future upgrades.
They maximize your ability to leverage your existing non-SharePoint programming skills.
They integrate cloud-based resources in smoother and more flexible ways.
They enable your extension to have permissions that are distinct from the permissions of the user who is running the app.
They can extend SharePoint Online websites as well as on-premises SharePoint websites.
Apps for SharePoint use one of the SharePoint client object models or REST endpoints to access SharePoint content and components. These client APIs enable SharePoint extensions that are designed for end users. (The end users in this case are site-collection administrators, website owners, and website members.) The server object model has APIs that enable programmatic extensions of SharePoint management, configuration, and security. These include extensions of Central Administration, custom Windows PowerShell commands, timer jobs, custom backups, and others. For more information about the kinds of administrative extensions you can develop, see SharePoint Foundation Administration. These administrative extensions are deployed in SharePoint Features that have farm, web application, or site-collection scope. Farm solutions are also installed by farm administrators, while apps can be installed by tenant and site collection administrators.
The server object model also has APIs for create/read/update/delete (CRUD) operations on lists, libraries, websites, and operations on other SharePoint components. This means that the server object model can be used for extensions that are intended for end users, but for reasons given in the preceding section, farm solutions are not usually the best choice for such extensions. Thus, it is no surprise that farm solutions cannot be installed on Microsoft SharePoint Online. Because Microsoft handles all the management of SharePoint Online, there is no need for administrative extensions. For more information (and a diagram) about the various APIs in SharePoint and where they overlap, see Choose the right API set in SharePoint 2013.
The client object models and REST endpoints do not duplicate the administrative-oriented APIs of the server object model. Moreover, because an app for SharePoint cannot contain custom code that runs on the SharePoint server, it cannot call these administrative APIs. Moreover, all Features in apps for SharePoint must have website scope. Thus, an administrative-oriented SharePoint extension is not really possible with an app for SharePoint. So the second guidance principle, but not an absolute rule, is that apps are for end users and farm solutions are for administrators.
A similar point applies to the fact that Features in apps for SharePoint cannot have site collection, web application, or farm scope. This doesn't mean that you give up some user interface (UI) element or functionality. It simply means that the implementation of the component moves out of SharePoint and onto a client or remote web application or remote database.
The following table lists the SharePoint components that cannot be deployed in an app for SharePoint and describes the "app way" of getting the same functionality.
If you want the functionality of ...
... try these approaches.
Custom Web Parts
An app for SharePoint can have remote pages that contain custom Web Parts. Another option is to expose a page from a remote web application in an app part on a SharePoint site page. The remote page can have essentially the same UI controls and functionality as a Web Part. For more information, see How to: Create app parts to deploy with apps for SharePoint.
Event receivers and Feature receivers
An app for SharePoint can contain functionally equivalent remote event receivers. For more information, see Handling events in apps for SharePoint.
Custom field (column) types
An app can deploy a new field (column) that is based on one of the existing field types. The Calculated and Computed field types are especially flexible. Another option is to present your data in a remote web page with customized controls or grids.
Custom web services built on the SharePoint Service Application Framework
You can develop your custom web services as remote services.
An app for SharePoint can include remote web pages that are available from every website on which the app is installed. An app can also use any of the built-in SharePoint Web Parts on site pages.
Some SharePoint components are used in end-user scenarios but do not have any equivalents in the SharePoint app model. For these you must use farm solutions.
Custom site definitions For more information, see Site Types: WebTemplates and Site Definitions.
Delegate controls For more information, see Delegate Control (Control Templatization).
Custom action groups and custom action hiding
User controls (.ascx files) No scenario actually requires these.
July 16, 2012