The Three and a Half Year Wait for a “Modern” SharePoint API

Why is this such a big deal?

Before SharePoint Online, developers building applications for on-premises SharePoint would typically choose the server-side SharePoint API to build farm solutions. This allowed for SharePoint customisations to run in-process which made life easier for developers but could result in issues that could compromise the performance and / or stability of a SharePoint farm. It was not unheard of for a rogue web part to take down an entire SharePoint site.

I am assuming Microsoft wanted to prevent these kinds of headaches affecting their cloud offering so they removed the ability for developers to use the server-side API for SharePoint Online. People writing sever-side code then had to choose between other APIs such as CSOM and REST to build their applications. CSOM became the first-choice API for many SharePoint developers.

Enter .NET Core

Microsoft surprised many people 2016 when it released .NET Core – an open-source, cross-platform version of the .NET framework. I was working for Microsoft back in the early 2000’s when Linux in the enterprise was seen as a huge threat to the company. Twenty years later I can build and run .NET applications on Linux, who would have thought?!

Our company was quick to adopt .NET Core and all new applications were built on it unless there was a valid reason to stay on the older .NET Framework. Unfortunately, there often was a valid reason – CSOM. Many of our products are built to integrate with SharePoint so the lack of .NET Core support for CSOM often came up as a blocker for us to use .NET Core.

Working without a .NET Core CSOM

The REST API became our first choice when writing server-side code but we found that we missed having a C# object model to use. In the end we built our own internal framework which provided a C# wrapper around the most commonly used parts of the REST API.

This worked well for the most part but we would occasionally run into issues where functionality we needed was not exposed via the REST API. Examples of this include doing a SystemUpdate on a list item and just about anything involving the term store. To work around this, we were able to make our own HTTP calls to client.svc using the SharePoint Client Query Protocol. This works but it is quite time consuming to understand the underlying protocol and build the XML packets required without the help of the C# CSOM API.

Hours of Lost Productivity

As a developer who spends a lot of time working with SharePoint on a daily basis, I feel the impact of those top two UserVoice items – .NET Core CSOM support and the lack of managed metadata support in the REST API all too often. Every time we have to manually write code to form an XML packet to call client.svc or figure out a cryptic programming issue caused by the lack of support for managed metadata it costs us time that we could be spending adding real features to our products to deliver a better experience for our users. Let’s hope that .NET Core CSOM support and a proper API for managed metadata are delivered in 2020 as promised.