CSOM is FINALLY available for .NET Core!

I don’t think anyone excpected that the 23rd of June 2020 would turn out to be such a crazy day. For years fresh developers of SharePoint have been surprised and in disbelief that the Client Side Object Model was not available for .NET Core. For some developers, who never even install Visual Studio, the premise of going “back to the old ways” could seem daunting and perplexing.

Today however, Microsoft saves the day by letting christmas, new years and thanksgiving come early, and provide us – finally – with support for .NET Standard (and thus .NET Core) with CSOM. Check out the announcement here: https://developer.microsoft.com/en-us/microsoft-365/blogs/net-standard-version-of-sharepoint-online-csom-apis/

Let’s dive in and check out what this means for us moving forward.

First off, there are some differences to the API’s. The .NET Standard version is missing some of the functionality of the .NET Framework version. Most notably, there is no support for on-premises SharePoint in the .NET Standard version. Further, there are some functions “missing” although it’s mostly legacy functionality that you shouldn’t be using anyways. What this means however, is that you can’t just update your .NET version and it will automatically work, you might have to do some modifications to make it play nicely.

I decided to try using just the command line and Visual Studio Code for creating this test, apparently that’s what all the cool kids are doing right now.

So first thing’s first: create a folder for the solution , naturally we’re going to run all the commands in the new Powershell Core 7!

Alright, we have our folder, time to fire up VSCode!

Visual Studio’s GUI has now been replaced with the “dotnet” command line interface, so to start, we’re going to just run:

dotnet new console

This creates a new project, a Program.cs-file and an obj-folder. Great! Now let’s just build and ensure it executes by running

dotnet run

The output from the sample is as expected

Excellent! Now we can start trying out the CSOM-code. First off, we need to load in the repository from Nuget. The syntax for that is dotnet add package.

Easy enough! Time to run some code!

So the first, and arguably most important thing Microsofts example shows us, is creating the ClientContext object. Funny enough, they underline the importance of setting FormDigestHandling to false. A property that’s been present in CSOM for a long time. In my project however, I get an error message saying it’s not part of the class. Bad luck i guess, we’ll just remove it.

The biggest difference between vanilla CSOM and .NET Standard CSOM is that you need to provide an access token no matter what. You can’t just apply a username and password to the ClientContext.Credentials like before. So luckily Microsoft has provided us with a nice AuthenticationManager class that helps get that access token. I decided to simplify it a bit though.

Their example, just calls the authorize endpoint to get an access token to an AAD-app.

So let’s head to the Azure portal and register a new app and give it some permissions to SharePoint.

We’re going to be signing in with a username and password, so i’m selecting delegated permissions for this app.

We’ll also need to register it as a “public client”, since we want to use the username and password flow.

We’re now all set, let’s simplify the example a looooooot and run this code in our new project (PS. Yes, there is no real “security” in this example by using SecureString, but it’s a good pattern to adhere to)

Running this in the terminal and we should yield the name of the web….

Hurrah! It’s running!

Let’s modify it and see if we can do some simple list operations:

Yup – works like a charm! This is really nice!

Final thoughts

  • Debugging and running C#-code in .NET Core is a BIG step forward for SP-developers. The debugging process is painless, modern and quite snappy.
  • There doesn’t seem to be any reason to delay moving to .NET Core, although migrating should be planned with care of course.
  • Probably the #1 reason developers will wait with moving over relates to authentication and waiting for PnP to update their codebase, especially concerning AuthenticationManager. Abstracting the work to obtain the access token will be a massive help. Also of course, ExecuteQueryRetry is a must for modern day CSOM-development.

All in all, this is a major big change for SharePoint developers, and one more nail in the coffin for .NET Framework.

Leave a Reply

Your email address will not be published. Required fields are marked *