SharePoint Development Methods

Published: Feb 5, 2019

Both SharePoint On-premise and Online (O365) leverage developers to build their custom functionalities and extend some of the SharePoint functionalities via custom development.

Multiple development options are available to achieve one’s requirement based on SharePoint version. One must have knowledge about various development approaches to hit the nail on the head.  

Through this blog, we are going to provide brief information related to some of the development ap-proaches. Let’s start our odyssey to learn below development approaches:

  1. Farm Solution
  2. Sandbox Solution
  3. SharePoint Add-ins
  4. SharePoint Framework
  1. Farm Solution

    Microsoft SharePoint introduced in 2001 but the first customization option i.e. farm solution was intro-duced in MOSS 2007. 

    The farm solution contains custom managed code which is deployed to the SharePoint farm servers and communicates with SharePoint via the server-side object model. The code related assemblies, XML, and other files in the extension are bundled into a single file called a solution package. The solution package is a file with .wsp extension but it has .cab-based format. This package contains SharePoint features and their related components.  

    Only a farm administrator is having access to upload/deploy a solution package into the farm’s solution store. A feature of farm solution can have the site collection, web application or whole farm scope. These solutions are used to customize SharePoint administrative functions, such as custom timer jobs, custom Windows PowerShell cmdlets, extensions of Central Administration, etc. 

    The assemblies of the farm solution always run with full trust, but an assembly can be deployed with custom code access security (CAS) system policy that gives the assembly less than full trust. Also, there are no resource usage restrictions.  

    The farm solution code is hosted in IIS worker process (W3WP.exe). When any developer deploys or ac-tivate/deactivate the feature, system’s IIS application pool recycle. The farm solution cannot be distributed through the Office Store and cannot be installed on SharePoint Online. 


    • Farm solution is the best solution to access server-side API in SharePoint server.
    • Assemblies are deployed with full trust and at farm level scope, provides more accessibility of farm to achieve some complex requirements.
    • Security will be intact as only farm administrator can deploy the solution in the farm. 
    • Highly dependent on .Net framework, provide more scope for customizations.


    • Farm solution is used only for SharePoint on-premise server.
    • Application pool recycles during the deployment of a farm solution. The site goes down during the deployment process.
    • If there is any loophole/error in the code, it will affect on whole SharePoint farm.
  2. Sandbox Solution

    Microsoft has introduced Sandbox solutions in SharePoint 2010 version. 

    Like to a farm solution, a sandbox solution is also a solution package (.wsp) file. But contradictory to farm solution, a sandbox solution authorizes the site collection administrator to install custom solutions without the interference of higher-level administrator. 

    The sandbox solutions are stored in the solution gallery of a site collection. The components of a sand-boxed solution run under a significantly restricted Code Access Security (CAS) policy and resource access restrictions.  

    The sandboxed solution can include code that runs against the SharePoint client-side object model. It is hosted in SharePoint user code solution worker process (SPUCWorkerProcess.exe).  

    A sandboxed solution runs outside of the IIS worker process. So, when any developer deploys or acti-vate/deactivate the feature, System’s IIS application pool does not recycle. The sandboxed solution packaged file runs only for site collection instead of the whole farm. 

    The developer can use Sandbox solutions in SharePoint on-premise version and online version with No Code Sandbox solutions to deploy per site collection and Site collection administrator can only install it. It will not run on cross-domain site.


    • Sandbox solution is used for both SharePoint On-premise and Online (O365).  Note: Currently, SharePoint Online only accepts no-code sandbox solution in SharePoint Online.
    • If there is any error/loophole in the code, it will only affect to that site collection instead of whole SharePoint farm.
    • Site collection administrator has sort of permissions to deploy a solution in the site collection.


    • It will not be compatible with cross-domain site.
    • It cannot be effectively used with resources files for the multi-lingual approach.
    • Custom workflow developed in Visual Studio cannot be deployed using sandbox solution.
  3. SharePoint Add-ins

    Microsoft SharePoint Apps was introduced in SharePoint 2013 version. Later, they are called  SharePoint Add-ins. 

    SharePoint Add-ins are self-contained extensions which may include cloud-based logic and data, Share-Point components, and client-side scripts, but not custom managed code that runs on SharePoint serv-ers. One can install them from either the Office Store or an organization add-in catalog. It can be in-stalled on either SharePoint on-premises farms or Microsoft SharePoint Online. 

    There are two types of SharePoint Add-ins: 

    • SharePoint hosted add-ins 
    • Provider-hosted add-ins
    • SharePoint hosted add-ins

    It is centered on the SharePoint components including lists, pages, Web Parts, workflows, and more. No server-side code is included in it. The business logic included in it uses JavaScript either directly on the custom SharePoint pages or in the JavaScript file which is referenced from the custom page. The JavaScript version of the SharePoint object model (JSOM) is available to make it simple for the add-in to perform CRUD (create, read, update, and delete) operations on SharePoint data. One can also customize the SharePoint controls by using a client-side rendering option and custom JavaScript. 

    The website, where the add-in is installed, is called the host web. From this site, the Add-ins are launched. The web site on which the add-in is deployed is called add-in web.

    The JavaScript included in the SharePoint-hosted add-ins can access data and resources that are outside of the add-in web. To access the data, there are two ways to safely work around the browser’s same origin policy: a special JavaScript cross-domain library or a specific JavaScript Web Proxy class. Using these two techniques, a SharePoint-hosted add-in can work with data on the host web, its parent subscription, or anywhere on the Internet.


    • The developer can add new functionality very easily in SharePoint server as well as in Share-Point Online.
    • Apps are executed outside the environment, any error/loophole in the code will not affect  other sites or site collections.
    • Installation steps are very easy compared to farm solutions.
    • Administrators can monitor the apps.
    • Multiple development platforms are supported for creating apps.
    • Users can easily get different apps from the SharePoint store.
    • Microsoft also offers a revenue sharing model for apps store.


    • App model relies heavily on JavaScript and REST API calls.
    • App parts are loaded in IFRAME in SharePoint site pages and many cross-server communica-tions for SharePoint client context impacts on site performance and UI experience of the site. 
    • Any customizations related to the master page is not feasible.
    • Provider hosted add-ins

    On contradict to SharePoint Hosted Add-in, the Provider Hosted add-in focuses around a remote web application or data source. It is not centered on the SharePoint components but can contain the SharePoint components. The business logic included in it is remote server-side code or code in non-Microsoft technology (e.g. Java, Python etc.). 

    All its components are hosted outside of SharePoint farm and it has at least one remote component hosted externally from the SharePoint farm or SharePoint Online subscription. 

    With .NET in presence of the implemented remote components, the managed code SharePoint Client-Side Object Model (CSOM) library is available. While without .Net, a set of REST/OData APIs can be used to access SharePoint data.

    To access SharePoint data through this add-in, its principal is required to be authenticated and authorized, and so the add-in needs permissions to perform operations on SharePoint data in the host web.

    It can handle SharePoint list and list-item events (e.g. adding an item to a document library) which the SharePoint Hosted Add-in can’t. It can also connect to any public or internal web service.


    • Client OM with C# can be implemented in the app.
    • .Net MVC and other non-Microsoft technologies (e.g. Java, Python etc.) can be used in the app.


    • It requires MS Azure or any other dedicated server to host the services for the app.
    • App parts are loaded in IFRAME in SharePoint site pages and many cross-server communica-tions for SharePoint client context impacts on site performance and UI experience of the site.
    • SharePoint Framework

      With the introduction of SharePoint Framework, a new way is opened for the users to experience modern web technologies and tools in a preferred development environment to build productive experiences and apps which are responsive and mobile-ready from the first day.

      The SharePoint Framework (SPFx) is a page and web part model which provides full support for client-side SharePoint development, easy integration with SharePoint data, and support for open source tooling. It works equally for both SharePoint Online and SharePoint on-premises (SharePoint 2016 Feature Pack 2 and SharePoint 2019).

      Some of the key features:

      • The controls are laid down in the normal page DOM, and responsive and accessible by nature.
      • Performance is reliable.
      • SPFx web parts can be added to both classic and modern pages.
      • The life cycle is accessible by the developer in addition to render, load, serialize and deserialize, configuration changes and more.
      • Runs in the current user context and connection in the browser.

      There is no dependency on any framework, one can use any framework for development like React, angular or knockout etc. It will not load inside in IFRAME. It’s run within the context of the same user browser.

      SPFx includes some client-side JavaScript libraries and other open source tool and libraries (E.g. node, gulp, npm, yeoman etc.) used for developing web part model.

      There are two approaches introduced in the SharePoint Framework:

      • Client-side JavaScript Injection
      • SharePoint Add-in


      • SharePoint framework provides mobile friendly and cloud-friendly solution.
      • It is very useful for customization in modern UI SharePoint Online sites.
      • It can be used in SharePoint Online and in SharePoint 2016 feature pack 2 & 2019 on-premise versions.
      • It can be deployed in classic pages as well as in modern web UI pages.
      • It provides support for other framework to develop solution with React, knockout, Angular JS.
      • SharePoint framework customizations are rendered in current page DOM object instead of IFRAMEs.
      • Various open source tools are available in the market for development.


      • It has certain limitations and bugs as the market is currently emerging, so it might happen that functionality provided in one version will be deprecated in the next update.
      • The process can initially be daunting if you are a .Net developer.
      • Lack of Visual Studio tooling, it’s hard to develop and to work with.
      • There is no store for customized web parts and extensions.


Now, through this blog one has an idea about the SharePoint development approaches. We have just highlighted the development approaches, one must keep into consideration  the pros and cons of the selected approach before selecting an approach based on one’s requirement.


  • Leave a message...

Related Articles

Power Apps – Portals (Part 3)

Sep 15, 2020

HIPAA Compliance Healthcare Software Development

Sep 9, 2020

Power Apps – Model Driven Apps (Part 2)

Sep 7, 2020