Newtonsoft.Json.dll release incompatible versions with same strong name

Created on 24 Jul 2015  路  7Comments  路  Source: JamesNK/Newtonsoft.Json

Newtonsoft.Json release incompatible versions with same strong name, only changing the File version.

Because of this any application, that use Newtonsoft.Json, breaks if other application puts different version of Newtonsoft.Json.dll into the GAC

According to MSDN (https://msdn.microsoft.com/en-us/library/wd40t7ad(v=vs.110).aspx)
"Assemblies that have the same strong name should be identical."

This issue can easily break applications that use microsoft frameworks (e.g. Mircosoft.Data.Odata),
Azure SDK and others

Every new version (even minor) must have new Assembly version. This is only way .NET can work properly

Most helpful comment

@sergey-litvinov @JamesNK

Yes some time you don`t have control and have to put in GAC
But problem even bigger.

Even if your application does not put this assembly to the GAC but some body else does, It will break your application as well.

Just imagine your application broken with some strange errors. It is not simple exception like "Can not load assembly version ..." no no no it would be Null reference exception some where deep in Newtonsoft.Json or some thing else.

And it is not even your fault. It is just because somebody installed other software, and that software decided to Newtonsoft.Json.dll to GAC

And then try to explain customers that it is broken because other software.
And of course customer need both peaces of software working on that particular computer.

All 7 comments

If something hurts, stop doing it. Don't put it in the GAC.

To @JamesNK

Even if our assembly not in the GAC it will still brake if someone (other application outside our control) will put their version into the GAC

Please read my question where I explain in details where actual problem is
http://stackoverflow.com/questions/31608983/newtonsoft-json-version-incompatibility

This question makes totally sense.
Following http://semver.org, the .Net assembly version should be set to Major.Minor (so that fix can transparently be applied).
File Version can be set to Major.Minor.[Patch.Build] or whatever increasing numbers you like. (about this file version, may be http://csemver.org could interest you).

my 5 cents. In some cases there is no other normal choice except GAC. For example Sharepoint uses GAC for packages that we install there, so if two packages use different assemblies but with the same version - dll hell starts again :(

I totally agrree. And that is why seriously considering SemVer should not be an option...

@sergey-litvinov @JamesNK

Yes some time you don`t have control and have to put in GAC
But problem even bigger.

Even if your application does not put this assembly to the GAC but some body else does, It will break your application as well.

Just imagine your application broken with some strange errors. It is not simple exception like "Can not load assembly version ..." no no no it would be Null reference exception some where deep in Newtonsoft.Json or some thing else.

And it is not even your fault. It is just because somebody installed other software, and that software decided to Newtonsoft.Json.dll to GAC

And then try to explain customers that it is broken because other software.
And of course customer need both peaces of software working on that particular computer.

We had similar problems with other assemblies, or solution was to build ourself, using our own snk file, so we get our own "strong name". That way, we can make sure we have unique version numbers, and the framework cannot load wront assemblies because it prefers GAC to local installation directory.
It's a shame that applications cannot suppres loading from GAC (or at least repriorize GAC to be searched after local directories...)

Was this page helpful?
0 / 5 - 0 ratings