App Approaches to Common SharePoint Customizations

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.

Customization

App Capability

Comments/Limitations/Alternatives

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.

Important Note

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.

Getting Creative

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.

Closing Words

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!

Great article, Richard. Regarding the branding elements, site columns, content types, etc, it's seems like much more work to deploy through an app. If all you are using is a declarative approach to deploying these artifacts (no feature receivers, no code) I think deploying as a Farm solution may still make sense. Alternatively, we have successfully packaged declarative elements as Sandbox solution and uploaded to the solution store. I know Sanbox is deprecated, but the trick is not to deploy an assembly with the WSP, which means you don't need the sandbox service running. Basically doing the same thing that an Design Manager export/import does, except it's not totally broken (please fix this!). As with all things SharePoint, it's all about tradeoffs.

Great points Wayne. You could probably argue that a declarative-only sandbox solution ISN'T a sandbox solution at all. A web template gets deployed through the same solution catalog and we certainly don't call that a sandbox solution.

Great post indeed. However, your suggestions to fill some gaps between farms solutions and the App Model is often to use the App Installed event. A serious limitation is that this is not supported by SharePoint-Hosted Apps.

You are right Stephane…SharePoint-hosted apps have a much more limited scope. I might get in trouble for this statement, but I consider SharePoint-hosted apps good for the "fart apps" of SharePoint. I use the term "fart app" because they tend to deliver a small/specific functionality instead of an elaborate solution. That said, cloud-hosted services can take SharePoint-hosted apps to the next level. For example, JSOM doesn't allow you to send emails, but I could call an external service to send emails. Are you or your organization/customers finding SharePoint-hosted apps being the more desirable?

"…. use the app installed event to add the web part page to the host web. …" I would like to do exactly this – add a webpart page to the host web using the app installed event and also add a few image viewer webparts with pre existing images. Can you point me to some material/book/video/blog/ anything at all to help me get started doing this? I have done custom development with SharePoint 2010 (and 2007) and have this mental block doing this level of custom coding. I was able to read custom list from host web using javascript.

EMT – Look for "Add an app event receiver" in the MSDN link below. Keep in mind this the app events are implemented server-side, so you will have to create a Autohosted or Provider-hosted app for SharePoint. It essentially adds a WCF service to your project that gets called by SharePoint:

Hank – apps have a smaller impact on the farm, since no assemblies are installed or run against w3wp.exe in the farm. As such, they have less impact on upgrade. They also have a MUCH simpler footprint (you just need a developer site collection instead of your own developer farm). I would also caution the statement "no plans to go to Office 365". You may not, but all CIOs are looking at the benefits of SaaS…it could surprisingly pop-up on your radar 🙂

It seems odd to me that we would ever use an App to deploy something to the farm that will not actually be used by the app itself. For example, you can use an App Lifecycle event to deploy a Content Type to the farm, but if the App isn't actually going to use that Content Type (or a related list), what's the point? In such a case, a solution is just cleaner. Are you suggesting that there are scnerios in which an App should be used solely as a deployment mechanism? I have certainly seen others advocating this idea, and I always wonder: What does the end user see when they launch such an app?

Hey Scot…as I tried out stress in the "Important Note" section, provisioning app elements outside the app web should be avoided. Apps are meant to be self-contained in provisioning and de-provisioning. I'm definitely not suggesting that an app be used solely as a deployment mechanism. But…this post was more focused on SharePoint Online organizations that are forced to work within the constraints of SaaS. SharePoint Online developers are "probably" better off using sandbox solutions to deploy declarative elements like content types to a host web. That said, it is hard for me to anticipate the types of solution scenarios these organizations would look to develop, so I'm simply trying to outline the options/constraints. Thanks!

Regarding Branding of Apps , I have a requirement where I need to apply custom Master Page i.e the Master Page deployed on the SharePoint Site to my App which is happening via a feature. Can you please provide some insight on how this can be done

The points are informative, could you please help me in this requirement: There are workflow custom activity(declarative) created in a farm solution. I am trying to access them in a workflow created in an app. Is it possible to do so. Thanks