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
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 ReadWhy “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!
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.
- “Performing cleanup” – Excel is stuck with an old, conflicted file and will never recover. - November 12, 2024
- How to add multiple app URIs for your Entra app registration? - November 5, 2024
- How to access Environment Secrets with GitHub Actions? - October 29, 2024
