[Video] SharePoint Online - Prefer PnP.Core over PnP.Framework

This is a transcript of a video published on the blog's YouTube channel except for one section. That section was omitted to keep the video under 5 minutes. This may be helpful for fellow developers who cannot view videos during their work.

Before discussing about PnP SDKs, please note that the first preference to interact with SharePoint Online should always be Graph SDK. That is the official stand from Microsoft. In case Graph API doesn't have the feature, go for SharePoint APIs or CSOM APIs. There are 2 different SDKs or nuget packages to interact with CSOM API from .Net applications. PnP.Framework and PnP.Core to name the nugets. Today we are talking about these 2 PnP SDKs what SDK we should choose and why one over the other?

As per the documentation the PnP.Core is the successor of PnP.Framework. In that sense PnP.Core should be our clear preference. One benefit they are advertising is that it can seamlessly switch between the modern Graph API and old SharePoint CSOM APIs. That will hide the API complexities from the developer and the developer needs to learn only PnP.Core. But there are more reasons than that to choose PnP.Core.

Number of lines

First of all PnP.Core requires less number of lines to achieve a task. Take the example of Getting the title of the web.

The left side is PnP.Framework code and the right side show PnP.Core. We can clearly see that the PnP.Core works with one less line. Compare this in an enterprise application with tens of thousands of lines.

Ease of use

Now let us look at the ease of use in achieving a use case. The example we are taking is the renaming of a folder in the document library. PnP.Core has a direct Rename method to do that. But PnP.Framework uses the move method with the new name.

Support for Dependency injection

The PnP.Core SDK has out-of-the-box dependency injection support. If we are using PnP.Framework, we need to write extra code to get the .net core model dependency injection.

Size of the request payload

The PnP.Framework uses one particular URL almost always. It is _vti_bin/client.svc/ProcessQuery.  This is the Fiddler screenshot of PnP.Framework making HTTP call to get a folder by relative Url. It uses HTTP POST to get data instead of HTTP GET. The request payload is XML format.Luckily response is in JSON. The XML requires more bytes than JSON for sending the same information. The different operations are achieved by changing the method attribute in the request payload. 

Now let us see how the same use case is done by PnP.Core. As we can see it uses HTTP GET with user friendly URL. No request payload at all. The response payload is relatively smaller than the PnP.Framework

Here is the side-by-side comparison between the two when querying for a folder by its relative Url. Left is PnP.Framework and right side is the PnP.Core.

Logging

Now coming to the logging aspects, PnP.Core is already following the .Net programming model and honoring the ILogger API. By adding the required configuration in the appsettings.json file we can get the logs into the required destination.

Observability

Observability is important to run a production workload. Tools such as Azure Application Insights normally log the URLs and their HTTP verbs. That will help us to understand the system behavior and also to troubleshoot issues. We have already seen that the Url is used by the PnP.Framework is mostly the same. Adding to that, it always uses HTTP POST with parameters to distinguish the operation which makes. We cannot distinguish the operation type by the HTTP verbs.

Error handling

In a normal web system, when an error happens it will return respective HTTP status codes. Never Http 200. Look a the fiddler trace when querying with non existing folder path from PnP.Framework. it always returns HTTP 200. In case it errors out, the error message will be inside. Production observability systems can never detect errors like this and proactively alert the dev team. 

Otherside, PnP.Core error out with proper HTTP status code. In case the folder URL is not present, we get HTTP 404 back, and will be handled properly by the production monitoring systems.

Contribution to Library

The PnP libraries are open-source and maintained by the community. Microsoft is not giving any warranty or support for these libraries. In case we end up facing an issue and need to get fixed quickly we need to fix ourselves and give a pull request.

Look at the source code of PnP.Core and PnP.Framework. The PnP.Core is relatively simple to understand. Meaning easy for us to fix the bugs in that library. It simply prepares the Url uses an internal method to execute that Url and returns the result.

Can we completely avoid PnP.Framework?

Not really. The PnP.Core is not a feature-complete SDK. There are features that are not available in PnP.Core.. In such situations, we need to use PnP.Framework. One place they are telling PnP.Core will eventually replace PnP.Framework. However, when a feature request was created to bridge the gap in CreateCopyJobs-related tasks, they informed PnP.Core is never going to implement that feature. In such situations we need PnP.Framework forever.

Thanks for reading. Comments are welcome.