5

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.

sashoalm
  • 75,001
  • 122
  • 434
  • 781
  • These versions are ancient. The current version is 10.x. People learned to avoid hard-coding specific versions in their pacakges many years ago. If there's anything at fault, it's using obsolete package versions, whether Json.NET or any other package that depends on ancient Json.NET versions – Panagiotis Kanavos Jun 20 '17 at 10:57
  • ServiceStack maybe? A lot of people stayed on 2.0, 3.0 when the licensing terms changed and encountered such incompatibilities – Panagiotis Kanavos Jun 20 '17 at 11:00

1 Answers1

11

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.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • 1
    Just to emphasize how pervasive Newtonsoft is: Microsoft's [JavascriptSerializer documentation](https://msdn.microsoft.com/en-us/library/system.web.script.serialization.javascriptserializer.aspx) recommends using the Newtonsoft library. It's uncommon for a library's official documentation to direct people to a competing library. – Brian Jun 20 '17 at 19:37