Server history
In the old days of SharePoint there was a single obvious choice to consider when building applications on the SharePoint platform. Microsoft Office SharePoint Server (aka MOSS, aka SharePoint 2007) introduced the Farm Solution with its Feature Framework and later SharePoint Server 2010 provided a safer incarnation of this with the Sandboxed Solution (aka User Solution).
During this time, a SharePoint application or extension would be built as a Sandboxed Solution if possible within the restrictions of this model, and otherwise would resort to being built using the Farm Solution model.
SharePoint Server 2013 introduced the App Model (now referred to as the SharePoint Add-in Model) which was intended an alternative to the Feature Framework based models. Importantly, the Add-in model supports applications running on servers outside of the SharePoint farm and using remote APIs to authenticate and utilise the services provided by the platform. This is a critical step towards ensuring the performance and availability of SharePoint irrespective of the Add-ins deployed to the environment.
Going online
Although initially supporting the execution of server-side custom managed code in SharePoint Online (SPO), Microsoft soon deprecated it and later deactivated it entirely. This left two approaches to creating deployable applications for both SharePoint Server and SharePoint Online. The Add-in Model and No Code Sandboxed Solutions (NCSS). The latter is a restricted variant of the Sandboxed Solution. It contains no managed code (no .NET assemblies) and is limited to defining change using declarative definitions (typically XML) which can include the definitions of Web Templates, Content Types, Columns, Master Pages, Page Layouts, Pages themselves and the web parts on them, and more but also for uploading JavaScript and CSS files.
Since this time, all code executing against SharePoint Online must be run remotely – be it an Add-in typically running managed code in Azure or a NCSS where any JavaScript provisioned runs in the client browser.
For completeness, Office 365 Apps provide yet another way to authenticate and execute code against SharePoint Online APIs and the Microsoft Graph among other endpoints. However, this article will limit itself to extensibility models that are suitable for both SharePoint Server and SharePoint Online.
Provisioning remotely
The term Remote Provisioning refers to the practice of deploying SharePoint assets such Sites, Lists, Content Types, Pages, and more by using an API that isn’t executed directly against a SharePoint server. Typically, this API is called from .NET managed code or JavaScript but could be utilised using any language and from any environment that is capable of issuing HTTP requests. Remote Provisioning is Microsoft’s preferred method of provisioning assets due engineering challenges on their end but declarative provisioning as part of a NCSS is in no way deprecated or unsupported.
Remote Provisioning excludes the built-in provisioning mechanisms available to Farm and Sandboxed solutions – the server-side API and declarative definitions of the Feature Framework. However, it doesn’t exclude these models completely as Remote Provisioning code may be written in JavaScript and deployed to SharePoint to be later executed in the client browser.
It is in this context that Content and Code approached the development of Fresh, our Internet solution. The solution needs to work both with SharePoint Server/On-Premises and SharePoint Online. It must also not have a dependency on non-SharePoint Infrastructure as for many organisations it’s not currently possible to host code in Azure. This is often due to it being an unrealised platform within the company rather than any technical or compliance reason. Even for clients who are already in Azure and totally satisfied, providing a solution with no external dependencies and no variable hosting costs improves our proposition.
It is primarily for this reason that Fresh is provisioned as a No Code Sandboxed Solution utilising a configuration/provisioning framework built upon JavaScript Remote Provisioning.
Looking forwards
With the recent hype around the SharePoint Framework (SPFx) this post wouldn’t be complete without mentioning it. Although the SPFx is a new deployable extensibility model for SharePoint, from a deployment perspective it piggy-backs on the existing Add-in model framework. In the context of Fresh it is a very appealing proposition because it brings a visual and configurable JavaScript-based extension framework to SharePoint and although it is deployed as an Add-in it provides a mechanism to produce partial page extensions (web parts) for SharePoint without a dependency on non-SharePoint Infrastructure (not including a CDN server).
Unfortunately, the framework shipped with limitations around the provisioning of SPFx web parts that prevented its being provisioned along with site templates. The modern page framework in which the web parts shine best was also limited in the way layout and common elements such as navigation could be applied.
Recent advancements such as SPFx Extensions in preview, communication sites providing modern pages with page layout mechanisms, and tenant scoped deployment of SPFx web parts go a long way to providing a platform suitable for an Intranet product. As this landscape matures to general availability in all areas we expect to be able to take full advantage of the new framework. We are committed to using the best engineering approaches for Fresh, and our investment in this area will continue.
Choose your model
[vc_row][vc_column][vc_cta h2=”How to Deliver Effective Communications in your Organisation” style=”3d”]The challenge for businesses in the modern age is keeping a consistent tempo to work; a reliability to workplace environments; leadership in operations and universal touchpoints that reach across the entire organisation. This whitepaper takes a closer look at the importance of internal communications in a changing business landscape and the role a company’s intranet plays in improving business fluidity and function.
hbspt.cta.load(4107501, ‘639bea14-4583-4a45-9e62-a372d9d07b13’, {}); [/vc_cta][/vc_column][/vc_row]