Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bondarchook opened this issue Jul 24, 2015 · 7 comments
Closed

Comments

@bondarchook
Copy link

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

@JamesNK
Copy link
Owner

JamesNK commented Aug 30, 2015

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

@JamesNK JamesNK closed this as completed Aug 30, 2015
@bondarchook
Copy link
Author

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

@olivier-spinelli
Copy link

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).

@sergey-litvinov
Copy link

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 :(

@olivier-spinelli
Copy link

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

@bondarchook
Copy link
Author

@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.

@markusschaber
Copy link

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...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants