SharePoint Development Methods

Technology changes have brought changes in the way businesses progress from the industrial era to now the internet world. Every business is progressing at a higher pace than ever before. Speaking specifically about software development companies, they are hellbent in developing cutting-edge technology solutions. Microsoft powered SharePoint solution offers a wide spectrum of tools and services for making business more productive and agile. SharePoint On-premise and SharePoint Online (Microsoft Office 365) helps developers leverage their custom development functionalities to build extended features for their application using SharePoint functionalities via custom application development.

SharePoint designer and development tools offer new functionality and multiple development options to SharePoint Developer . SharePoint development includes building custom SharePoint solutions for end user with the help of various features like site templates, workflows, lists and so on. Businesses can achieve their goals based on the SharePoint solutions they are working on.    From developers to end-users, many people work alongside SharePoint. So, SharePoint developers must have knowledge about various development approaches to hit the nail on the head.

Through this blog, Our Sharepoint Development Team is going to provide insightful  information related to some of the development approaches and techniques. So without much ado, let’s start our odyssey to learn Sharepoint development methods and approaches. There are basically four types of Sharepoint development methods

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

1. Farm Solution

Microsoft SharePoint introduced this method in 2001 and since then they have been evolving in the technology aspect with their first SharePoint customization option i.e. farm solution introduced in MOSS 2007.

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

Only a farm administrator has access to upload/deploy a solution package into the farm’s solution store. A feature of farm solution is that it has the site collection, web application and whole farm scope of development. SharePoint farm solutions are used to customize SharePoint administrative functions, such as custom timer jobs, event receivers, custom Windows PowerShell cmdlets, extensions of Central Administration, etc.

The assemblies of the farm solution always run with full authenticity, but an assembly of several others 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 on the IIS worker process (W3WP.exe). When any SharePoint developer deploys or activates/deactivates the feature, the system of IIS application pool starts to recycle. The farm solution cannot be distributed through the Office Store and cannot be installed on SharePoint Online (Office 365).

Pros

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

Cons

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

2. Sandbox Solution

Microsoft has introduced Sandbox solutions in the SharePoint 2010 version.

Just like a Farm Solution, a Sandbox solution is also a packaged solution (.wsp) file. But contrary to Farm solutions, a Sandbox solution authorizes the site collection administrator to install custom solutions without the interference of higher-level administrators.

The Sandbox solutions stores all the information in the solution gallery of a SharePoint site collection. The components of a Sandbox Solution perform under significant restriction of Code Access Security (CAS) policy and Resource Access Restrictions.

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

A Sandbox solution runs outside of the IIS worker process. So, when any Sharepoint Consultants deploys or activates/deactivates this feature, the system’s IIS application pool does not recycle. The Sandbox solution packaged file runs only for site collection instead of the whole farm.

SharePoint Development Company can use Sandbox solutions in SharePoint on-premise version and SharePoint 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 a cross-domain site.

Pros

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

Cons

• It will not be compatible with cross-domain sites.
• 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 App was introduced in the 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.

• 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 includes the use of 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. You can also use the add-in to perform CRUD (create, read, update, and delete) operations on data. SharePoint developers can also customize the 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.

Pros

• Sharepoint Consultants can now easily add new functionalities in SharePoint server as well as in Share Point Online.
• Apps are executed outside the environment, without any error/loophole in the code which will not affect other SharePoint 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.

Cons

• App model relies heavily on JavaScript and REST API calls.
• SharePoint Site Theming: App parts are loaded in IFRAME in SharePoint site pages and many cross-server communications 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 the contradiction to what hosted SharePoint Add-ins offer, the Provider Hosted add-in focuses around a remote web app or data source. It is not centered on the SharePoint components but it can also 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 fundamentals are 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.

Pros

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

Cons

• It requires Microsoft Azure or any other dedicated server to host the services for the SharePoint apps.
• SharePoint Site Theming: App parts are loaded in IFRAME in SharePoint site pages and many cross-server communications for SharePoint client context impacts on site performance and UI experience of the site.

4. 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 for SharePoint Developers:

• 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 SharePoint 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

Pros

• SharePoint framework provides mobile friendly and cloud-friendly solution.
• It is very useful for customization in a modern UI SharePoint Online site.
• It can be used in SharePoint Online and in SharePoint 2016 feature pack 2 & 2019 on-premise versions.
• SharePoint Developer can deploy it 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.

Cons

• 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.
• At the same time, 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.

Conclusion

Our idea of creating this blog was to enlighten businesses with SharePoint development methods and approaches  that they should adopt for SharePoint Development Projects. For SharePoint Solution Development, based on your business objective, you can choose one or more models of SharePoint development framework while working with either SharePoint On-premises or SharePoint Online. Through this blog, we have highlighted all the essential factors responsible for choosing one or multiple models of SharePoint development and their selective pros and cons, one must keep into consideration before selecting a method.