CSOM suddenly throwing exceptions when trying to access list contents in SharePoint? A weird fix.

3 min read.

This article explains one possibly reason why some C# code, powered by CSOM, suddenly stops working and can’t access a SharePoint list anymore that it could before, throwing annoying and misleading exceptions like “The list is not DocumentLibrary, VersionPolicies is not supported” instead.

Oh – and of course, there’s a fix as well. Well, possibly a workaround? But at least it’ll get you going.

But as usual, before going into the steps to fix the issue, let’s take a step back and take a look at the actual problem a bit more.

Problem

Table of Contents

The screenshots below are from an environment I used to reproduce the issue. “Inbox” is my special list (well – a Document library) that I created for this use case.

You can see, that the list is, in fact, a Document library. It doesn’t currently have any items, and my integration is supposed to access the list, read the contents and perform some irrelevant tasks based on the files in the library.

In my CSOM code, I could enumerate all of the lists on the Site. Even my special list called “Inbox”.

So far, so good.

Looking at the properties of the list/library/what have you, it shows “List.EnableVersioning” to be True for my list. Looking at some other lists, such as UserInfo (which my list COULD in fact read properly), the EnableVersioning flag was False.

Not sure what to make of that, but thought it might be helpful to log this for future reference, just in case.

And my code in particular was reading the list like this:

That looks successful (like CSOM calls often do), but trying to actually load the list throws.

Here’s the exception in readable form:

Microsoft.SharePoint.Client.ServerException: 'The list is not DocumentLibrary, VersionPolicies is not supported.'

And the stacktrace doesn’t help much:

   at Microsoft.SharePoint.Client.ClientRequest.ProcessResponseStream(Stream responseStream)
   at Microsoft.SharePoint.Client.ClientRequest.ProcessResponse()
   at Microsoft.SharePoint.Client.ClientRequest.<ExecuteQueryToServerAsync>d__53.MoveNext()
   at Microsoft.SharePoint.Client.ClientRequest.<ExecuteQueryAsync>d__39.MoveNext()
   at Microsoft.SharePoint.Client.ClientRuntimeContext.<ExecuteQueryAsync>d__57.MoveNext()
   at Microsoft.SharePoint.Client.ClientContext.<ExecuteQueryAsync>d__23.MoveNext()
   at ...

I have also seen this simply returning a 404 (which would make more sense than “VersionPolicies is not supported”, if you ask me!), but it’s frustrating you can seemingly get either one. Anyway, the exception and the associated stacktrace are below:

Microsoft.SharePoint.Client.ServerException: 'List 'Inbox' does not exist at site with URL [url]'
   at Microsoft.SharePoint.Client.ClientRequest.ProcessResponseStream(Stream responseStream)
   at Microsoft.SharePoint.Client.ClientRequest.ProcessResponse()
   at Microsoft.SharePoint.Client.ClientRequest.<ExecuteQueryToServerAsync>d__53.MoveNext()
   at Microsoft.SharePoint.Client.ClientRequest.<ExecuteQueryAsync>d__39.MoveNext()
   at Microsoft.SharePoint.Client.ClientRuntimeContext.<ExecuteQueryAsync>d__57.MoveNext()
   at Microsoft.SharePoint.Client.ClientContext.<ExecuteQueryAsync>d__23.MoveNext()
   at ...

Still, the bottom line is that even though the Document Library is definitely there, but you still get an error.

But what’s causing this?

Reason

The nonsensical exception threw me off a little bit, but after some investigation I realized that one thing had changed.

If you KNOW the libraries are there, and especially if the same code used to work before, it might be the same thing for you.

Namely, SharePoint has started to support Sites.Selected permissions scope, even for “FullControl” and “Manage” permission levels. And perhaps this particular environment – and this app – is now using those permissions, and you don’t have enough permissions to actually access the lists.

I know, I know – sounds far-fetched, right? But that’s exactly the reason I ran into this issue.

Someone with enough permissions to change stuff had changed the permission scopes for my application to be Sites.Selected, and whatever configuration they had done meant that my code could still read some data from the site, but couldn’t actually read the list items.

Solution

Solution is going to be quite straightforward. Your app does not have enough permissions to access this list due to Sites.Selected authentication scope missing, and SharePoint Online error messages are not up-to-date yet

So what you might need to do, is to grant your application permissions to your site. Handling the Site-scoped authorization flow is a little bit complex in code, but luckily there’s a PowerShell module you can use! Namely, the ever-so-trustworthy PnP PowerShell.

With PnP PowerShell, you can do it like this:

Connect-PnPOnline https://contoso.sharepoint.com/sites/siteName -Interactive

Grant-PnPAzureADAppSitePermission -AppId '[your-app-id]' -DisplayName 'YourSitesSelectedApp' -Site 'https://tenantname.sharepoint.com/sites/sitename' -Permissions Read

Why “Read”?

The options are “Read”, “Write”, “Manage” and “FullControl”. “Read” is the least amount of permissions, and you should start with that.

I actually needed to write to the site, too, so I granted myself “Write” permissions, and it helped. But technically speaking you should only get “Read” if you don’t need more than that 😉

Okay – with that confusion out of the way, you should be good immediately after running the command to grant the permissions.

Hope it helps!

Author
Recent Posts

Antti K. Koskela

Developer / Speaker / Consultant at Koskila / Precio Fishbone / Norppandalotti Software Co / Alter - Experience Ideas Ltd

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as Solutions Architect for Precio Fishbone, building delightful Digital Workplaces.

He's been a developer from 2004 (starting with PHP and Java), and he's been working on .NET projects, Azure, Office 365, SharePoint and a lot of other stuff. He's also Microsoft MVP for Azure.

This is his personal professional (e.g. professional, but definitely personal) blog.

Latest posts by Antti K. Koskela (see all)