CouchbaseNetClient confusion with regards to Newtonsoft.Json and Common.Logging

I have seen a series of strange issues regarding CouchbaseNetClient’s dependencies:

  1. When you add CouchbaseNetClient to a solution, how does NuGet decide to write the version information that CouchbaseNetClient requires? What are CouchbaseNetClient’s actual expressed desires to NuGet? What min/max version of Common.Logging and Newtonsoft.Json does it want?

  2. Are there known problems with Newtonsoft.Json 6.x or 7.x with CouchbaseNetClient? Sometimes I’ve see package conflicts, and resolved them by moving to 7.x, and some times I see runtime crashes ( Runtime Error FileLoadException while initializing a Couchbase class, which will then load Newtonsoft.Json dependency required by CouchbaseNetCLient).


@wpostma -

First of all, it depends on which version of the CouchbaseNetClient package you install from NuGet. I’ll assume the latest (2.1.4 at the time of writing).

  1. You have a couple of questions here, so I’ll answer each:
    a) From the NuGet dependencies on the couchbase-net-client project itself
    b and c) The client is built against NewtonSoft 6.0.1 and requires Common.Logging >= 2.1.0
  2. Not that I know of specifically - you should be able to upgrade both to their latest versions via NuGet with no problems.

The problem with 3rd party dependencies is that a) they change all of the time and b) not all organizations are on the cutting edge, so including (or enforcing) the latest means they cannot upgrade the SDK, which is counter to our goals when we do a release. Also, depending upon the type of project you create, the dependencies may already by included (ASP.NET and NewtonSoft for example) and you are forced to upgrade your version.

I hope that helps.


What’s weird is that on my computer, with Couchbase client 2.1.4, it’s selecting Newtonsoft.Json version 3.5, when I look in my Packages.config.

Do you think NewtonSoft Json 7.0 should still work, or is redirecting to 7.0 a bad idea?

I must admin I’m not an expert in C# packages, and what they call .Net Framework Assembly Unification, which is I believe the name for whatever is going on that might have redirected Couchbase’s link to Newtonsoft.Json away from the 6.0.1 to some other value. An explicit assemblyBinding and bindingRedirect are sometimes required to work around this:

  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
        <bindingRedirect oldVersion="" newVersion="" />

The above goes in the section of App.config.

@wpostma -

I haven’t confirmed, but using 7.0 should probably work. Just use the NuGet packet manager and the “Updates” tab on the left. It should also handle all of the binding redirects for you. I have noticed that’s sometimes better to remove any bindings in your app.config before updated.


I am not sure why, but the app.config bindings appear automatically while doing the Install-Package CouchbaseNetClient into a brand new application.

Removing the auto-added ones also tends to avoid problems, or else, bump the redirect to a instead.

@wpostma -

Try enabling auto-binding redirection:


In your .sln files…this should solve your problem.