Share via

Part 2 - Introduction to SharePoint 2013 App Model

  • Article

This post is in continuation to my previous post "Part 1 - Why Apps are needed for SharePoint 2013", wherein I had explained that there have been some issues with fully trusted SharePoint 2010 applications, they can destabilize the whole farm and they are difficult to migrate to newer versions of SharePoint.

The new SharePoint 2013 application model not only addresses concerns around solution packages, custom code on server, but also introduce a lot of new capabilities.

Key points about SharePoint Apps

  • Everything is in a SharePoint site is now an app
    • Yes, everything in a SharePoint site is an app. This includes lists and libraries. Though the actual implementation of lists and libraries has not changed. They are referred in user interface as apps, to create a more unified experience. For e.g. if you would like to create a new document library, you need to create an app and pick document library and then name it.

 

  • No custom code on SharePoint server
    • As per the new SharePoint 2013 App Model, SharePoint apps do not live in SharePoint, rather they execute within a browser client, or in non-SharePoint server such as IIS server or in cloud server such as Windows Azure. SharePoint apps are granted permissions to get back into SharePoint sites via OAuth and communicate with SharePoint via REST/CSOM.

 

  • Easier to upgrade to future versions of SharePoint
    • This is possible because the apps are running against client side service 

 

  • Reduces the ramp-up for those developing apps
    • Developers building SharePoint apps don't need to be familiar with SharePoint specific things  e.g. object model. If they want to work with data from SharePoint, then they have the option to leverage some of the standard services or CSOM.

 

  • Leverage hosting platform features in new apps
    • If you develop an app which is going to run in another hosted platform (like Windows Azure OR non-SharePoint server such as IIS server OR any other infrastructure) but it's going to use SharePoint UI such that end user feels that he is in SharePoint and the app looks like SharePoint. However, since the app is running in another environment like Windows Azure, then you can use the capabilities of hosting platform i.e. Windows Azure, which you normally cannot do in SharePoint.
    • This enables taking SharePoint apps to different levels - further than what can be done with farm/ sandboxed solutions

 

  • Provides additional approach for development
    • The app model does not replace the solution based approach of development/deployment, it is an additional option. Thus, in SharePoint 2013 for development, we can use either of the following approach:
      • SharePoint Apps  
      • Fully trusted solutions
      • Sandboxed solutions

 

Which development approach to use - SharePoint Apps, Farm Solution or Sandboxed solution?

It is important to understand the differences between the three development models which we have i.e. SharePoint Apps, fully trusted solutions and sandboxed solutions.

 

Farm Solutions

Sandboxed Solutions

SharePoint Apps

When to develop?

Use farm solutions only when you cannot achieve the same via apps

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.

Recommended approach - Develop an app whenever you can

Use Server-Side SharePoint API

Fully trusted solutions allow developers to write code that can use server side API.

They are also called as partially trusted solutions. Server side code runs under a strict CAS policy and provides limited capabilities.

Server side code running of SharePoint server is strictly prohibited in apps. Any server side code that needs to be used within your app needs to run and hosted outside SharePoint on a different server such as cloud or a different IIS server.

Use Client-Side SharePoint API

Yes

Yes

Yes, and the capabilities provided by client side SharePoint APIs in SharePoint 2013 is much more as compared to previous versions.

On-Premise Deployment Friendly

Custom code in these solutions is deployed to the bin directory or to GAC. Code can be secured using CAS policies but is typically runs inside full trust. 

These type of solutions are deployed by farm administrator.

They can be uploaded and deployed by site collection admins and owners. It has limited set of APIs available from server side SharePoint.

In addition server side code cannot make request to externally hosted web services or databases. Though developers can use client side solutions to call external services and even make cross domain calls.

Yes

Hosted Deployment and Cloud support

Farm trusted solutions cannot be deployed in hosted SharePoint deployment. They are only available in on-premise deployment.

Sandboxed solutions are the only type of solution that can be deployed to hosted SharePoint installations.

Yes. In addition, developers will be able to publish their apps to a public marketplace for download & purchases. In addition organizations will be able to create a private corporate marketplace where the apps would be available to the organization.

Install/Upgrade/Uninstall

With these type of solutions, developers should manually code each of type of activity logic when solutions are upgraded or uninstalled

Similar to farm solutions, developers need to write code to write logic when solutions are upgraded or uninstalled.

Microsoft has made a lot of investments in install/upgrade and uninstallations of apps to make it end user friendly experience and to ease out developer challenges.

Server Outages

When error occurs in these, they can affect the service app pool and in worst case can even host server outages. 

These are the most unrestricted type of solutions that can be deployed in SharePoint 2013.

Runs on the server farm, but in a dedicated isolated process. Thus, they are considered safe and cannot cause server outage.

Apps run isolated from a SharePoint farm and cannot cause SharePoint server outages.

Authentication Options

The components in the solution can, and usually do, run in full trust.

The components in the solution run in partial trust.

 

 

 

Before you can call SharePoint APIs from your app, you need to authenticate to SharePoint. Which authentication mechanism you use depends upon where the code of your app is running.  

  • Inside SharePoint: You have to use HTML and JavaScript, and authentication is already taken care for you.  
  • In the cloud:   
    • Use client-side code along with the cross-domain library
    • Use server-side code along with OAuth
    • REST APIs

  

What can be developed?

Almost all components can be deployed as Farm solution.

Refer to this link to understand in detail what can be implemented in Sandboxed Solutions in SharePoint.

Some of the most common things a sandboxed solution cannot do are: 

  • Connect to resources that are not located on the local farm
  • Access a database
  • Call unmanaged code
  • Write to disk   
  • Access resources in a different site collection

 

What Can be Created as Apps -  

  • Custom Web Parts (remote pages that contain custom Web Parts)    
  • Event receivers and Feature receivers(remote event receivers)
  • Custom field (column) types
  • Custom web services built on the SharePoint Service Application Framework Application pages  

What cannot be created as Apps -  

  • Custom site definitions
  • Custom themes
  • Custom action groups and custom action hiding User controls (.ascx files)
  • Delegate controls

 

In my next post, I will discuss Apps Hosting and Branding - wherein I will mention about app hosting options, different types of apps, entry points, user experience and branding.

Comments

  • Anonymous
    March 21, 2013
    Very very nice post. I am impressed with your post and wrote my understandings on SharePoint app modelwww.sureshpydi.blogspot.in/.../sharepoint-2013-app-model.html

  • Anonymous
    December 03, 2013
    Great post for people who are starting with SharePoint App Models. Thank you for providing such clear and comparable concept.

  • Anonymous
    January 31, 2014
    Thanks Amit, you are just playing the role of Sharepoint 2013 teacher for many of us

  • Anonymous
    March 18, 2014
    Very good and easy to start...!

  • Anonymous
    May 05, 2014
    Thanks.Good article ,very useful for beginners in SP2013 app development .

  • Anonymous
    May 11, 2014
    Awesome post... just what is needed for a beginer in APP Model!

  • Anonymous
    June 15, 2014
    Thanks.... its very useful for a beginer in sharepoint App model.

  • Anonymous
    December 02, 2014
    Great stuff :) really helpful to understand I am also looking for learning Sharepoint core solutions - biggner  level please share me some resource like this

  • Anonymous
    January 11, 2015
    Thanks for sharing. this is very useful information.

  • Anonymous
    May 20, 2015
    excellent...this is what I was looking for

  • Anonymous
    July 05, 2015
    Great article. thanks.

  • Anonymous
    January 28, 2016
    Good article. There is few more additions to App-limitations that I could think about -

  1. SharePoint Custom Timer-Jobs cannot be deployed as Apps in SharePoint-2013
  2. Custom List-Definitions cannot be deployed as Apps
  3. Also converting a simple event receiver (list) to a remote event-receiver is an unnecessary overhead.