Why is Newtonsoft.Json so prone to assembly version conflicts?

Question

I have noticed that we often get assembly version conflicts in our project, and 90% of the time it's Newtonsoft.Json at the bottom. There are many questions on SO specifically for Newtonsoft.Json conflicts - the infamous "Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0" for example. Searching for "assembly 'Newtonsoft.Json, Version=6.0.0.0" gives 37 questions - a lot of them highly upvoted. Or this one about 4.5.0.0.

Is there any explanation why this happen so often with that library specifically instead of others, and why is it such a consistent source of assembly version conflicts? It definitely happens more often than with other libraries.

Answer 1

Why is Newtonsoft.Json so prone to assembly version conflicts?

Basically, because it is commonly used as a downstream dependency by other libraries and application code. If you have package A (in this case, Netwonsoft.Json), and you have:

SomeApp
-> A

then all is great; but if you have:

SomeApp
-> A
-> SomeLib
   -> A

or:

SomeApp
-> SomeLib
   -> A
-> SomeOtherLib
   -> A

or:

SomeApp
-> A
-> SomeLib
   -> A
-> SomeOtherLib
   -> A

or:

SomeApp
-> A
-> SomeLib
   -> A
-> SomeOtherLib
   -> YetAnotherLib
      -> A
      -> MeTooLib
         -> A

then all the referenced versions of A need to be the same, or suitable assembly-binding redirects need to be in place to allow a lib that expected version 7 to silently accept version 10 without throwing a binding issue. Of course, you're still completely out of luck if the API is not binary compatible between versions 7 and 10 in a method that the older library uses.

So basically: this is a problem of popularity and re-use, and a symptom of other libraries not keeping up to date on their downstream dependencies. Json.NET sees this more than other libraries because it is used more than many other libraries, including as a dependency of other libraries.

Note that NuGet automatically adds binding redirects.