Ran into the above error message when I upgraded my CSOM DLL’s to the latest available version via NuGet. This awesomely descriptive error message is trying to tell you that CSOM is receiving a response from the server which it doesn’t understand well. Your best bet is reverting to the DLL versions you were previously using when it did work 😉
By the way, I got this error trying to import a search configuration XML file.
I’m stil struggling a bit on why I got this error, as I’m using the latest CSOM DLL’s to talk to Office 365, you would expect that to work. So expect an update with some more background info in the near future.
Update: as I expected, it did have something to do with the upgrade. As you might know from previous posts I’m using spmeta as a provisioning framework. The version I was using was compiled against version 16.0.x.x of the CSOM DLL. The upgrade I did brought me to version 16.1.3912.1204. Note that Microsoft switched from 16.0 to 16.1 because they wanted to prevent overlap with packages that use the redistributable version of CSOM (which will remain 16.0).
I expect the problem is then caused by objects / calls passing through multiple versions of the frameworks. I’m not entirely sure, but I do know that using just one version solved the issues for me. So how do you get a NuGet package to use a different DLL version than the one it was compiled with? Assembly binding redirections. Add the following code to your app.config (or web.config):
<assemblyIdentity name="Microsoft.SharePoint.Client" publicKeyToken="71e9bce111e9429c" />
<bindingRedirect oldVersion="0.0.0.0-22.214.171.124" newVersion="16.1.3912.1204" />
The .NET framework will now ensure that even assemblies that want to use an earlier version will be served the new 16.1.3912.1204 version. Repeat the <dependentAssembly> section for all of the CSOM assemblies you’re using. And remember to update the version number when it changes. Enjoy!