Versioning problem

Nov 4, 2013 at 7:04 PM
Nov 5, 2013 at 12:15 AM
Nov 5, 2013 at 6:14 AM
Yep, I saw that later as well. Bad, bad decision. You can simply nuke any application that uses newtonsoft.json assembly by installing an older version into GAC.
Nov 5, 2013 at 11:58 AM
Note that I am not affiliated with this project - to be honest, I don't really know enough about .NET assemblies to have an opinion on this. I was just pointing out the maintainer's position.
Nov 5, 2013 at 12:13 PM
Sure and thanks for the link (not arguing with you or anything).
OTOH I am quite surprised by the lack of concern in general.
Coordinator
Nov 11, 2013 at 11:48 PM
I'm looking at ways to fix this. Possible solutions will be to change Json.NET to change GetEnumerator back to an explicit implementation in 6.0 or to increase the assembly version number.
Nov 12, 2013 at 6:26 AM
Hi James,

Glad to see that you are on this.
IMHO the only solution is to version it properly. I am not an expert in assembly binding but it looks like to me that GAC is a huge problem in this case even if there are no breaking changes - it takes control away from you which is really really bad as any application can interfere into yours.
Dec 13, 2013 at 6:33 PM
Edited Dec 13, 2013 at 6:42 PM
I'm not sure if this is related, but I think it is. If I put the .NET 3.5 version of the DLL in the GAC, when I have a project in Visual Studio that targets .NET 3.5, it seems to somehow think the DLL in the GAC is .NET 4.0 because I am recieving build errors such as:

Note I have a project structure like:

Project "Some"
Project "Some.Shared"

Some.Shared has a ref to "Some" and "Some" has a reference to the JSON DLL

The primary reference "Some.dll" could not be resolved because it has an indirect dependency on the .NET Framework assembly "System.Deployment, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.