SharePoint 2013 Development (Apps versus Solutions)

SharePoint 2013 is a strong development platform for building solutions and apps addressing different requirements and needs.

There’s a plenty of documentation on MSDN and TechNet to get you started with building your first application and how to consume the different capabilities of the platform.

But one thing I struggled to find is when and why you would use a SharePoint App rather than using the object model?

This blog will walk you through that specific question and how to answer it.

Before we start there’s no rights or wrongs here, it all depends on what the customer needs and the best way to tackle the requirements

The first factor is where is my code being hosted?

If you are using the object model most of your code will be within the SharePoint host environment:

• Managed solutions also known as farm solutions will be hosted within the main SharePoint worker process (w3wp.exe).
• Sandbox solutions will run within the SharePoint sandbox worker process (SPUCWorkerProcess.exe).

If you are using Apps:

• App code never runs within the SharePoint host environment.

So what difference does it make?

1. If the custom code is not running within the SharePoint farm this will eliminate any kind of custom operation being done within the farm and hence increase the farm stability.
2. It’s easier to upgrade if your code is platform independent, we have seen many cases where the customer will hold all the SharePoint migration until he makes sure that all the custom solution will be working fine on the new version.
3. The deployment, most farm solutions require a Farm Administrator to do the deployment and mostly restarts the IIS on all the WFEs, which causes a disruption in the service. Although the deployment of Sandbox solutions is a lot easier and straight forward but there’s no indication on whether or not it’s safe to activate this sandbox solution without actually activating it and giving the code inside aces to all the site collection’s content.
4. Office 365 Ready, you can always use Sandbox solutions on Off365, but mostly you would develop two versions from your code one that works with On-Premise farms and another one for Office 365. Now the whole point of an App is you don’t worry where it’s hosted or deployed as it should behave the same on both On-Premise and Cloud environments.

Apps are very different from solutions in that they run 100% outside of the SharePoint server, and their custom code executes either within the context of the client browser or on other servers that are not running SharePoint such as Web servers in the cloud.

There are three high-level types of SharePoint apps:

• SharePoint-Hosted: These types of apps are manifested within SharePoint generally without external dependencies. Any custom business logic implemented with custom code must run within the context of the browser client. Some examples of these types of Apps could be an expense calculator or holiday request. Each of these Apps may implement its own business logic using JavaScript, but they can also access and leverage SharePoint lists and libraries.
• Provider-Hosted: These types of apps may have a SharePoint component but the bulk of the business logic is manifested in some other infrastructure, such as an external Web server or in the cloud. These types of apps are a good option when integrating an existing event registration or help desk ticketing solutions within a SharePoint site.
• Auto-Hosted: These types of apps are similar to the Provider-Hosted Apps in that they have the bulk of their business logic and/or data storage manifested externally. What’s different with an Azure Auto-Hosted app is that the app package contains the website & database in the package. When the app is installed in a site, SharePoint handles the automatic provisioning of the database (as a SQL Azure database) and website (as an Azure hosted website) using an account that has been setup by the SharePoint farm/tenant administrator.

One explicit limitation of the SharePoint App Model is that server side code is explicitly prohibited from residing on the SharePoint farm as part of an App. Any server side code that is utilized in the context of an App must be hosted outside of SharePoint either in the cloud or on-premises.

The Cloud App Model provides a loosely coupled architecture for building Apps in SharePoint 2013. This loosely coupled architecture gives the freedom of choice for developers in the technologies they use to not only host their applications, but also the tools they use to write them. Apps can leverage industry web standards such as HTML, JavaScript, jQuery, JSON, REST, OData and OAuth to provide an integrated user experience.

• Full trusted solutions can be installed on any scope (Farm, Web App, Site Collection, Sites).
• Sandbox solution or partially trust solutions is scope is limited to Site Collections

• Apps has two different scopes :
  • Site Scope: in this case the app is installed and launched within the same scope of the SharePoint site.
  • Tenancy Scope: in this case a special SharePoint site is required called app catalog, once it’s installed users from different sites can choose to connect and consume this App.
• Using the object model whenever we need to scale our solutions either up or out ; We needed to introduce new hardware to the farm that comes with the package of :

1. Down time considerations
2. Cost
3. High Availability and Disaster recover changes
4. Monitoring

• Using the App model you can always scale your application without affecting the current SharePoint environment.

Have a look at windows Azure Scalability options

https://www.microsoft.com/en-us/download/details.aspx?id=36837

• Previously our only options to integrate with other applications was rather through BCS (Business Connectivity Service), Web Services or build your own service application, this provided the end users with limited experience integrating with external applications.

• Using the new App model there are too many options for the integration from Services to actually implementing a fully customized applications against different products SDK.
• All the web skills are reusable in building the Apps, to a very good extent you can write a SharePoint app without needing to know a lot about SharePoint 2013.
• Fully supported templates from visual studio 2012.
• Device free in terms of the device on which the code runs. The possibilities include a server in the SharePoint farm, an external server such as a server in the cloud, a client computer, and a mobile device.

Conclusion

Always develop Apps whenever it’s possible rather than developing a classic Full Trust or Partially trust solution.

Bear in mind that sandbox solutions are still supported but they will be deprecated.

But first understand that the client object models and the REST endpoints that are available in the App model do not duplicate all of the APIs of the server object model that are accessible in a classic SharePoint solution.

For more Information :

Reference documentation

Apps for SharePoint compared with SharePoint solutions

Choose the right API set in SharePoint 2013

https://msdn.microsoft.com/en-us/library/jj164060.aspx#Factors

SharePoint 2013 Development

https://msdn.microsoft.com/en-us/library/jj162979.aspx

• Anonymous
  March 31, 2013
  Hi, the SharePoint Development Technology Decision Chart could help also to chose the right approach: www.fiechter.eu/.../Post.aspx

• Anonymous
  April 28, 2013
  I have to push back against your approach, from an on Premise implementation, the use of APPS is not a good fit. Why, well Apps for on Premise environments have issues with Extranet's, SSL's and the big on, does not support AAM's.. Wow. be careful when architecting your solutions and understand scope and future planning, public facing sites with multiple Zones like WWW and Authoring will not support the App model.

• Anonymous
  May 19, 2013
  On-premise apps work with both SSL and support AAM since the March 2013 public update. See the following links for instructions: technet.microsoft.com/.../dn144963.aspx technet.microsoft.com/.../fp161237.aspx (comments on SSL about halfway down the page)

• Anonymous
  February 16, 2014
  information was good.<a href="http://staygreenacademy.com" > Rozeena </a>

• Anonymous
  October 07, 2014
  Good one ..

• Anonymous
  January 10, 2015
  APPS VS SOLUTIONS..... APPS ALWAYS PREFERABLE

• Anonymous
  November 08, 2015
  Fantastic post. Clearly illustrate the use of App in SharePoint. i would like to ask a question. App is isolated, running from a different web server. so when an app is being installed in a site collection and triggered, which account is being used to fulfill the triggered action? account i meant by SPAdmin or other service account used. Hope you can clarify my doubt. thanks.

• Anonymous
  November 09, 2015
  The comment has been removed

• Anonymous
  December 30, 2015
  Nice Blog.. thanks.. gallery.technet.microsoft.com/.../App-Configuration-in-Dev-f6666c37

• Anonymous
  January 13, 2016
  custom application development services help a modern-day enterprise keep pace. your own type getting it developed from a Software Application Developer.