SharePoint Development Methods

Published: Feb 5, 2019

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 services offers a wide spectrum of tools and services for making business more productive and agile. SharePoint has On-premise and Online (O365) services that helps developers leverage their custom functionalities to build extended features for their application using SharePoint functionalities via custom application development.

Sharepoint design and development tools offer multiple development options that are available for businesses to achieve their goals based on the SharePoint version they use currently. 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 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, 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.

    Pros: 

    • For any SharePoint development Company, 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, 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 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 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 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 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.

    Cons:

    • 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 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 SharePoint data. Sharepoint developers 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.

      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 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.
      • 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 the contradiction to what hosted SharePoint Add-ins offer, the Provider Hosted add-in focuses around a remote web application 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 app.
      • .Net MVC and other non-Microsoft technologies (e.g. Java, Python etc.) can be used in the app.

      Cons:

      • 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.
  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:

    • 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.
  5. 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 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.

    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.
    • 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. Based on your business objective, you can choose one or more models of SharePoint development framework.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.

Comments

  • Leave a message...

Related Articles

Things you must know before choosing Power BI

Nov 26, 2020

What are ORMs and How does it work?

Nov 24, 2020

Introduction of Azure DevOps Pipelines

Nov 19, 2020