How to create SharePoint Online add-in with ASP.NET Core 2.1

While support of .NET Core for SharePoint CSOM libraries on its own way (still no ETA), you can create a SharePoint add-in with ASP.NET Core 2.1 today. Of course, it adds some inconveniences, but at least you can target the latest version of ASP.NET. I’ve created a sample project at GitHub here so you can easily try it. This post describes how to configure everything to run it.

First of all, a few drawbacks worth mentioning:

- you can’t use F5 experience in Visual Studio for convenient debugging. Instead, you should manually upload your app into a site and attach Visual Studio to running web application.

- you can’t target a project to netcoreapp. Obviously you can’t do it because SharePoint CSOM for .NET Core is not available yet. That’s why you have to retarget your project to .NET Framework instead. Which means that you lose cross platform feature. If that’s essential thing for you, then you should wait for official .NET Core support. 

- solution described here only works for SharePoint Online. On-premises is a completely different story and out of the scope of the post

Let’s get started. More...

Stylelint with SPFx integration

Are you TypeScript developer? I bet you use tslint in all your TypeScript projects! If not – start using it. SharePoint framework has tslint step which validates your code against tslint rules, which is awesome. More and more web developers today also use stylelint. Stylelint can be easily explained in just three words – linter for css/scss. Modern web developer (and of course modern SharePoint developer) has to write a lot of css or scss code. So why don’t we lint css code as well? Checkout increasing interest in stylelint at npmtrends:

SharePoint Framework in current version doesn’t have built-in stylelint support. However we can easily fix it with custom gulp subtask. Let’s do it right away! More...

What’s new and what’s changed in SharePoint Online REST API in October 2018

It’s November and it’s time to review changes in SharePoint REST API in October with help of SharePoint RESE API Explorer. As usual I have to put below caution:

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

With REST API explorer you can navigate between different endpoints, explore their structure, methods, classes and parameters. REST API explorer uses _api/$metadata endpoint to get the REST API data, parses it and presents in tree view format. REST API explorer also stores historical $metadata results in Azure storage making it possible to compare $metadata results we have today and month ago. More...

What’s new and what’s changed in SharePoint Online REST API in September 2018

A few months ago I’ve created a site, where you can explore SharePoint REST API - SharePoint REST API Metadata Explorer. With REST API explorer you can navigate between different endpoints, explore their structure, methods, classes and parameters. REST API explorer uses _api/$metadata endpoint to get the REST API data, parses it and presents in tree view format. REST API explorer also stores historical $metadata results in Azure storage making it possible to compare $metadata results we have today and month ago. I’ve added a new section to REST API explorer called SharePoint REST API Change Log. With change log you can explore what was changed in SharePoint APIs in the last few months. More...

Calling MS Graph API from classic SharePoint pages

- Classic pages you said?

- Yes! You read it right. MS Graph API from classic SharePoint page. However please read it first:

That’s not an official or recommended way. That’s just a proof of concept, which uses some tenant features introduced with SPFx 1.6. That’s something I decided to try out when SPFx 1.6 was out. Use it on your own risk.

When to use it? On classic pages if you don’t have an option to execute SPFx code.

So what if you want to call some MS Graph APIs from your classic SharePoint page? No problem then.

Before doing actual coding, we should check that we meet all prerequisites:

  • You have SPFx 1.6 features, which work without issues in your tenant. You can test it by creating a simple SPFx web part, which uses MS Graph. Upload it to the app catalog, approve the request to MS Graph and see it actually returns MS Graph data

If above works, you have everything needed for our experiments. More...

Using PnPjs to send requests to MS Graph with SharePoint Framework 1.6

SPFx 1.6 was released recently and a lot of new and interesting features were introduced. AadTokenProvider, AadHttpClient, MSGraphClient  went to GA, which are my favorite features. One of the common thing in SPFx development is accessing other resources, protected with Azure AD. For example you might have your LOB API with Azure AD protection and you want to consume that API from SPFx web part (extension). Before SPFx 1.6 it was a bit challenging, because you have to deal with cookies attached to your asynchronous http request or with custom “patched” adal.js implementation. SPFx 1.6 features mentioned earlier drastically simplify the task to access Azure AD protected resources. Now you can access Azure AD APIs (including Microsoft APIs like MS Graph) from SPFx with ease!

I’m pretty sure you know about PnPjs library. It has a lot of cool features, among them a fluent interface to SharePoint and Graph API. WIth SPFx 1.6 release you can use PnPjs as your Graph client without hassle. Read further to find out how. More...

SharePoint lifehacks: create SharePoint app registration with client secret which never expires

I bet you know about a page in SharePoint with address AppRegNew.aspx. You use this page to create a new app registration, generate ClientId and ClientSecret. One important thing about ClientSecret generated with AppRegNew.aspx is that that secret has expiration time. By default expiration is 1 year. You can easily replace it afterwards, there is an article out there - Replace an expiring client secret in a SharePoint Add-in. You can even generate a new one with maximum of three years of expiration. Sometimes it’s inconvenient, especially if you have to manage multiple SharePoint apps with different expirations. Do you know, that you can generate a secret, which never expires? Well, technically almost never, but 300 years is pretty good, isn’t it? My ex-college found a way to do that, read further to find out how. More...

Web Components in SPFx world: Vue vs Stencil

This year I hear “Web Components” term from here and there more frequently. What exactly is Web Components?

Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.

In other words, web components are reusable pieces of HTML and JavaScript, which can be used in modern browsers, and what is even more important, can be consumed by JavaScript frameworks. Today we have a few web frontend libraries for building web interfaces and SPAs. All of them uses concept of components, however components from one library can’t be easily ported to another one. It looks weird, because in the end that’s just portion of html + styles + logic (JavaScript). However today, in 2018 we can’t reuse building blocks from one library in another. It’s a shame. Web components solve that issue. They can be reused across JavaScript frameworks. Check out webcomponents site for more information.

Web components is a set of W3C standards, which describe how everything fits together in browser. Not all browsers fully supports all web components’ specifications. Google Chrome has full support, Firefox is developing a few remaining things and Edge has the worst support: More...

Diving into AadHttpClient (with hacking!)

Consuming third party or your own Azure AD protected API from SPFx code is a very common need. I wrote a blog post series on that topic, the first one you can find here. All solutions I covered have their own pros and cons, however the less painful and recommended solution is AadHttpClient (available in SPFx 1.6 and onwards). AadHttpClient approach has less issues and works really good. If you are curious about how it actually works, read the rest of the post. In this post I dive into AadHttpClient architecture, libraries and technologies used, think about security issues and try to bypass (spoiler: successfully) webApiPermissionRequests restrictions in SPFx web parts. More...