How to use Remote Event Receivers with .NET Core (or .NET 5) and PnP.Framework

In June 2020, a .NET Standard version of SharePoint CSOM was released. It means that now we can build projects for SharePoint, that target multiple platforms. At the beginning of 2021, a .NET Standard version of PnP-Sites-Core was also released (with a brand new name PnP.Framework and an updated codebase). However, there are some limitations in the .NET Standard version of SharePoint CSOM. Especially the lack of Remote Event Receivers (RER). The whole namespace was dropped. In some cases, you cannot replace RER with Webhooks without loss of functionality. Sometimes you just need RER or you're upgrading your code and cannot migrate RERs to webhook, since that's expensive. 

So, let's bring support of Remote Event Receivers back to .NET Core \ .NET 5+.

The source code sample for this blog post is available at GitHub here (the master branch contains code for .NET Core, if you're looking .NET 5 sample, use net5 branch). More...

SharePoint development state in 2020: story based on sharepoint.stackexchange analysis with Power BI

The year 2020 is over and once again it's time to perform regular analysis of data at sharepoint.stackexchange. This is the fourth edition of such an analysis. 

Tools used to collect and analyze data: 

  • Power BI with Power BI Desktop - super cool tools for data analysis. If you don't have experience with Power BI, it's worth trying to see what is possible. When I first tried it a few years ago I was sooo impressed with power yet simplicity in performing data analysis and building visualizations. It works very well for both simple and advanced scenarios. I believe that everybody will find these tools useful for any kind of data analysis. 
  • DaxStudio - an extremely useful tool to test your DAX queries. 
  • Power BI Community - Power BI has a very strong community. I found a lot of answers at their forum, I even asked some questions and community helped with valid answers. That's not a "tool" but worth mentioning. I am grateful for all the answers.
  • Stack Exchange API

The source code used to gather initial data is available at GitHub. More...

SPFx overclockers or how to significantly speed up the "gulp serve" command

A few months ago I wrote an article about SharePoint Framework build performance - SPFx overclockers or how to significantly improve your SharePoint Framework build performance. I've tried to reduce the amount of time the "gulp serve" command uses to re-build your code and to finally refresh a browser. I used different optimization technics for that purpose. The idea was to tweak the default SPFx build pipeline. However, those post only partially solves the problem. 

In this post, I will solve the problem from another way around (spoiler: I managed to make "serve" 10-15 times faster). 

The idea

How SharePoint Framework's "gulp serve" works? It gets your sources and outputs javascript bundles. But "gulp serve" becomes slow when your solution grows. How to fix that issue? Well, since it's slow, then don't use it! 

So this is the idea - don't use "gulp serve", use a completely custom webpack based build to transform your sources into exactly the same javascript bundles which are produced by "gulp serve". 

What is the input for "gulp serve"? - TypeScript sources, styles. What is the output? - Javascript files. Can we get sources and produce exactly the same javascript? -Yes.

How it works

Some nerdy content goes below. If you don't want to read about internal implementation, go directly to "How can I use it?". 

Also please note, that the internal implementation was changed since this post was written, however the main idea is still the same.

To make it work, we need a custom webpack config and webpack dev server to serve webpack output. More...

What’s new and what’s changed in SharePoint Online REST API in August-October 2019

I continue exploring REST API changes using my tool called SharePoint REST API Metadata Explorer. Here I post only some interesting findings, the full log is available for you on the SharePoint REST API Metadata Explorer web site under the "API Changelog" tab. 

Disclaimer

Please note, that all changes are gathered from Targeted tenant. Most likely these changes haven’t been officially introduced yet, use this post as spoilers to potential upcoming features. If you want to use APIs mentioned here in production, please check corresponding official documentation to make sure they are available.

AI, Machine Learning and Knowledge hub

The previous week was "Ignite" week. A lot of new things were introduced. Including innovations in the AI area. More...

Exploring The Microsoft Graph Toolkit

At the end of September 2019, Microsoft released The Graph Toolkit library.

a collection of reusable, framework-agnostic web UI components that work automatically with Microsoft Graph

It was in preview for a while, now it's in GA, thus it's a good time to start exploring what is available in this library.  

First of all, that's a set of components, which abstract a lot of things about MS Graph, authentication, UI away from a developer. It provides a very seamless interface for building UI components. UI elements are built with web components technology - which means that they are framework agnostic. You can use it with any modern JavaScript framework.

Let's explore how to use this library with a React-based single page application and with SharePoint Framework. More...

What’s new and what’s changed in SharePoint Online REST API in March-April 2019

What's new and what's changed in SharePoint REST API in March in April 2019? Explore the most interesting changes (additions and updates) here! 

Just a quick reminder, all data come from my SharePoint REST API Metadata Explorer. Go to the "API Changelog" tab and see what's changed in recent months in SharePoint REST API. 

Disclaimer

Please note, that all changes are gathered from Targeted tenant. Most likely these changes haven’t been officially introduced yet, use this post as spoilers to potential upcoming features. If you want to use APIs mentioned here in production, please check corresponding official documentation to make sure they are available.

Organizational News (aka authoritative news)

In the previous episode, I mentioned that OrgNews endpoint was added. Now, when corresponding PowerShell cmdlets (Get-SPOOrgNewsSite, Set-SPOOrgNewsSite, Remove-SPOOrgNewsSite) to manage Organizational news sources (also known as authoritative news) were announced, you can also use REST API to list all organizational news sources. However, I haven't found a way to add or remove authoritative news sources using the REST API. More...

What’s new and what’s changed in SharePoint Online REST API in January-February 2019

I haven't posted about changes in REST API for a while, because nothing interesting was really happening inside REST API in December-November. But now we have something new to explore! 

Just a quick reminder, all data are coming from my SharePoint REST API Metadata Explorer. Go to the "API Changelog" tab and see what's changed in recent months in SharePoint REST API. 

Disclaimer

Please note, that all changes are gathered from Targeted tenant. Most likely these changes haven’t been officially introduced yet, use this post as spoilers to potential upcoming features. If you want to use APIs mentioned here in production, please check corresponding official documentation to make sure they are available.

Organizational News

This item was in the roadmap for a while. You will be able to "mark" a site as "organizational news source". When viewing news from "organizational news source" you will see an indication that this news is "organization news". Nice feature to distinguish global company news from department news. More...

Introducing SharePoint Typed Item - Visual Studio Code extension

When working with SharePoint as a developer you often need access to SharePoint data. If you use TypeScript you expect that all data will be strongly typed. However, it's not a case if you work with SharePoint dynamic data like lists and libraries. 

Consider the code below written with PnPjs:

sp.web.lists.getByTitle('Clients').items.get()
      .then((items: any[]) => {
        for (const item of items) {
          console.log(item);
        }
      });

or with SPHttpClient inside SharePoint Framework solution: 

this.context.spHttpClient.get(`${currentWebUrl}/_api/web/lists/getByTitle('Clients')/items`, SPHttpClient.configurations.v1)
      .then((response: SPHttpClientResponse) => {
        response.json().then((items: any[]) => {
          for (const item of items) {
            console.log(item);
          }
        });
      });

In both cases, you don't know the type of items beforehand and have to use any type (items: any[]). What's wrong with any type? In TypeScript it's considered as bad practice. Of course you can and should use any in some edge cases, but in general, it's considered as bad. With any type you don't have type intellisense in vscode, you lose type checking if you want to use your variable elsewhere. So how to fix it? 

To fix it you should create a separate interface manually and describe all needed fields. In that case instead of any you use: 

items: Client[]

While it works, it has a few drawbacks: 

  • you have to create all needed interfaces manually
  • if you have a need to access additional fields, you will have to go and update corresponding interfaces
  • if you (or team members) add a field to a list, you will have to go and update corresponding interfaces

What if there is a tool, which generates all required always up-to-date interfaces for you?

This is exactly what SharePoint Typed Item does - it takes your configuration and outputs TypeScript interfaces based on SharePoint lists, libraries and content types. 

Read further to find out how to get started with SharePoint Typed Item extension. More...