|NOTE: This post takes an aggressive bias towards the new apps model for SharePoint customizations. Well written farm solutions are a solid and time-tested approach to customizations in on-premise deployments. Regardless of the sentiment in this post, Apps for SharePoint DO have gaps compared to farm solutions (hopefully the Harvey Balls below illustrate that). The purpose of this post is not to pitch app model propaganda, but to help outline the gaps and perceived gaps. Apps are the only hope for customers in SharePoint Online or those with aspirations to move there in the foreseeable future.|
I have spent the last year traveling the world and authoring numerous posts/solutions to evangelize SharePoint development using apps for SharePoint. Apps for SharePoint are incredibly powerful, but many SharePoint developers still gravitate to farm solutions based on familiarity and misconceptions on the “limitations” of the app model. I’m confident that almost ANY SharePoint solution can be delivered in the app model with good understanding and a little creativity. To support my case, I decided to assemble a comprehensive list of common SharePoint customizations, evaluate their support in the new app model, and provide alternate solutions where feasible. Although it is clear that gaps exist between apps and farm solutions, alternatives are available in my cases. Feel free to send me a note if you feel I’m missing something from this list.
|Alternate CSS (in hive)||Apps cannot deploy files to SharePoint’s root files/hive. Instead, css can be deployed to SharePoint using a module or app installed event.|
|Alternate CSS (in module)||Apps can use modules to deploy css to SharePoint, but only to the app web…not the host web. Referencing css from an app web can have inconsistent results in a host web across depending on the users browser and browser settings. As an alternative, a app installed event can be used to deploy css to a host web.|
|Alternate CSS (apply)||Apps can leverage an app installed event to apply alternate css to a SharePoint site. This is similar to using feature receivers in farm solutions for the same results.|
|App for Office||Deploying an app for Office inside SharePoint solution is completely new in 2013 and fully supported using apps for SharePoint. This can be a very powerful components to include in solutions, as is outlined in this post|
|Application Page||Apps cannot deploy files to SharePoint’s root files/hive, which includes the layouts folder. As an alternative, web part pages can be deployed through a module or app installed event receiver.|
|Column||Declarative columns can only be deployed to the app web…not the host web. If you need to deploy columns into the host web (ex: a content syndication hub), you can leverage an app installed event to provision columns programmatically in the host web.|
|Content Type||Declarative content types can only be deployed to the app web…not the host web. If you need to deploy content types into the host web (ex: a content syndication hub), you can leverage an app installed event to provision content types programmatically in the host web.|
|Custom Action||Apps support only specific types of custom actions, including ribbon commands and context menus in both the app web and host web. These can be very powerful when combined with dialog boxes, but do not cover the full spectrum of custom actions available to farm solutions (ex: Site Actions menu).|
|Delegate Control||Apps for SharePoint do not support “Control” elements that can be used with delegate controls in a master page. Delegate controls are a common mechanism for swapping out functionality of a site using a farm solutions (particularly useful with the AdditionalPageHead delegate). As an alternative, the same result can be achieved through the design in a custom master page (ex: place specific html or server controls in the master page).|
|Feature Receiver||Apps have remote events for “App Installed”, “App Uninstalling”, and “App Upgraded”. All of these can be used in a similar way to feature receivers in farm solutions. It should be noted that app remote events do not implement reliable messaging.|
|Feature Stapling||Apps can be “stapled” through the app catalog. This has more flexible rules than traditional stapling, allowing specific sites, managed paths, or site templates to get apps pushed to them. The app catalog even provides a mechanism for app retraction. However, apps installed through app stapling share a single app web (from the app catalog) and app remote events only fire during installation into the catalog. For more information, see my post a few months back on “app stapling“.|
|Field Type||Custom field types require files to be deployed into SharePoint’s root files/hive, which is off limits to the app model. As an alternative, apps can easily deploy custom forms that can leverage almost any web/html controls imaginable. Custom field types have been discouraged, so this approach is even better than farm solutions IMO.|
|Image (in hive)||Apps cannot deploy files to SharePoint’s root files/hive. Instead, images can be deployed to SharePoint using a module or app installed event.|
|List Definition||Apps can deploy custom list definitions, but only to the app web and not the host web.|
|List Event Receiver||Apps for SharePoint can deploy remote event receivers that provide similar functionality to list event receivers in farm solutions. However, they can only be deployed to lists/libraries in the app web, not the host web.|
|List Instance||Declarative list instances can only be deployed to the app web and not the host web. If you need a list provisioned in the host web, you can alternatively look at provisioning the list programmatically into the host web using an app installed event.|
|Master Page (in hive)||Apps cannot deploy files to SharePoint’s root files/hive. Instead, master pages can be deployed to SharePoint using a module or app installed event.|
|Master Page (module)||Apps can use modules to deploy master pages to SharePoint, but only to the app web…not the host web. Referencing a master page from an app web can have inconsistent results in a host web across depending on the users browser and browser settings. As an alternative, a app installed event can be used to deploy a master page to a host web.|
|Master Page (apply)||Apps can leverage an app installed remote event to apply a master page to a SharePoint site. This is similar to using feature receivers in farm solutions for the same results.|
|Module||Apps can leverage modules to declaratively deploy files into SharePoint. However, they can only deploy to the app web. As an alternative, a app installed event can be used to deploy files to a host web.|
|Script (in hive)||Apps cannot deploy files to SharePoint’s root files/hive. Instead, script can be deployed to SharePoint using a module or app installed event.|
|Script (module)||Apps can use modules to deploy script to SharePoint, but only to the app web…not the host web. Referencing script from an app web can have inconsistent results in a host web across depending on the users browser and browser settings. This also poses a cross-domain issue for the script. As an alternative, a app installed event can be used to deploy script to a host web.|
|Search Configuration||The query side of search is largely re-architected in SharePoint 2013 and supports the export/import of search configuration. Apps for SharePoint can be used to consistently and efficiently deploy a search configuration to a number of sites!|
|Service Application||Cloud-hosted apps for SharePoint (Provider and Autohosted) can deliver similar functionality to service applications. Apps can have tenancy permissions and configured to make app-only API calls (ex: outside the context of a user). It all depends on the desired integration and capabilities to determine if an app is an acceptable alternative.|
|Site Definition||Site definitions deploy files into SharePoint’s root files/hive, which is not a capability of apps for SharePoint. As an alternative, consider web templates, “app stapling”, or controlling the provisioning process.|
|Theme||Although I would question the sanity of someone looking to create a theme (we seem to change themes in each release of SharePoint), they can be deployed through an app module (to app web) or app installed event (to host web). This includes the new “composed looks” in SharePoint 2013 that include several files (master pages, theme color palette, fonts, images, etc).|
|Timer Job||An external process (ex: worker role) can deliver similar functionality to a timer job given the app has tenancy permissions and the ability to perform app-only calls. It all depends on the desired integration and capabilities to determine if an app is an acceptable alternative. I did this for media encoding in this solution and for site collection provisioning in this solution.|
|User Control (controltemplates)||Apps cannot deploy files to SharePoint’s root files/hive, which includes the controltemplates folder. As an alternative, user controls can live in the remote web of an app and used in some similar ways to a user control in controltemplates, but not as delegate controls or page directives in SharePoint pages.|
|Web Service (ISAPI)||ISAPI web services (under the _vti_bin url) are deployed to the root files/hive of SharePoint, which is off limits to apps. As an alternative, “Cloud-hosted” apps for SharePoint (Provider and Autohosted) can host custom web service in their remote web|
|Web Part||Apps can deploy “App Parts” (also called Client Web Parts) to SharePoint, but these can only have certain types of custom properties (string, int, bool, enum) and cannot use native web part connections. As an alternative, App Parts can leverage postMessage APIs to communicate to SharePoint (and possibly to each other).|
|Web Part Page||A web part page is simply an .aspx file deployed through a module. Apps support modules, but only to the app web and not the host web. An alternative is to use the app installed event to add the web part page to the host web. I give this a 50% because it would be impossible to add web parts declaratively to the web part page using this approach (would have to be programmatically or through the UI)|
|Web Template||Web templates live in the solutions catalog of the host web’s site collection root. An app installed event can be used to deploy a web template .wsp to the solution catalog, but cannot activate it.|
|Workflow||Workflow is re-architected in 2013 to be declarative and is completely supported in the new app model.|
|Workflow Activity||Workflow is re-architected in 2013 to be declarative and is completely supported in the new app model.|
Apps for SharePoint are designed to leverage the app web for all SharePoint things it needs. The app web is a hidden sub-site under the host web that provides isolation for the app. This is why ALL the declarative elements of an app are deployed to the app web and not host web (ex: modules, columns, content types, etc). Apps are architected this way so they leave no trace of themselves on the host web when they are uninstalled. The list above mentions the use of the app installed event to deploy elements to the host web. This is NOT an appropriate practice for general app development, especially apps that are designed for the Office Store. The approach is more appropriate for internal development, including customers moving to SharePoint Online or with extensive farm solutions.
I have two creative tips that have helped me close the gap between apps and farm solutions:
- Control the provisioning process…by doing this, you can tack on just about anything you can imagine using CSOM before you hand the site over to a user. This includes, branding, specialized permissions, feature activation, etc. I recently authored a solution that shows how to do this with the app model (even provisioning site collections). You can find that solution here.
- Add App-only Permission to your app…doing this allows your app to call SharePoint APIs outside the context of a user. This is enormously helpful for long running processes/jobs or from other apps. The solution referenced in tip #1 also uses this approach.
Beyond the list above, it is important to recognize the numerous benefits of the new app model. Apps for SharePoint do not run server code on the SharePoint farm, making them much safer to run (including in SharePoint Online) and don’t impact upgrades/service packs. They are cloud-ready and cater to the numerous HTML/JS developers in the world, opening the door to numerous solution possibilities and cost efficient developer resources. One of the biggest advantages I’ve realized is in my development environment. In the past, I’ve carried a huge laptop with multiple cores and 32GB or memory. This was required because SharePoint assemblies weren’t remoteable, requiring a full SharePoint server to be an effective developer. Today, I can use almost anything with a browser and a developer site collection (add Visual Studio for cloud-hosted apps). The picture below is my new SharePoint development machine and my old development machine…ahhh life is good!