applejag/Newtonsoft.Json-for-Unity

DLL clash when using com.unity.collections because it uses an internal Newtonsoft JSON package

nothke opened this issue · 4 comments

Expected behavior

No clashing DLLs

Actual behavior

Error caused by 2 same DLLs. One coming from this package and the other from Unity's internal Newtonsoft JSON package.

Steps to reproduce

  • New project
  • Import jillejr.newtonsoft.json-for-unity via UPM
  • Import Collections package via the package manager (tick show preview packages)
  • Clash!

Details

Unity has an internal Netwonsoft JSON package, which is used by com.unity.test-framework.performance. Meanwhile, Unity Collections depend on that performance testing framework package, and hence will use the internal Newtonsoft JSON. It is impossible to decouple those, therefore it is not possible to use advanced DOTS collections with this repo in the same project.

As Unity has it's own Newtonsoft JSON package, they for sure will use this in the future. Is it possible to change/rename the dlls in this repo so they don't clash with the Unity's own Newtonsoft JSON package?


Edit by @jilleJr: If you stumble upon this issue, please see @kjungyoun's solution at the bottom of this issue thread: #86 (comment)

Hi @nothke! Thanks for reporting this!

It's a bit complicated but generally, no, I won't release a separate package with a renamed assembly. It would be more to maintain for me and in these cases if you could use their internal package instead by adding a reference to "com.unity.nuget.newtonsoft-json": "2.0.1-preview.1"

I think this is better to be reported to Unity though. Unity is fighting some DLL hell, which NuGet has already fought and has so far done pretty good for itself, while Unity is facing all these issues again.

What would be nice here is if their Unity package was not tightly locked to using any Newtonsoft.Json package, but instead let you as a user configure which one to use. Like if you could override com.unity.test-framework.performance to use my package instead.


For their own internal package that you linked, from v2.0.1-preview.1 they actually just copied my v12.0.101 release, so it should work quite alright as-is. It's missing some bug fixes I've added since, but nothing too major. Don't know if they've worked on it past that.

I had a discussion with a Unity developer before about this whole case. The discussion was about:

  • should they take over the repo, or
  • should they fork it and have their own copy while I have mine.

Only relying on my package could sadly not be decided, because I'm still just a third-party to them, and it would be a huge security hole for them to blindly just forward my package's binaries to all Unity users.

At the time of that discussion, which for now is around 1-1.5 years ago I think, we decided that they will try to fork my repo, analyse it, and republish it, and then maintain their own copy totally separate from mine. When their package has surpassed mine in features and can support the same range of Unity versions that I do now, then I will mark this repo as "archived" and simply refer to their package instead.

Even though they're a big company, they do not have enough resources to put into such a package, so they've not maintained it as well as one might expect from them. Today that "archive" deadline is moving further and further away because I sometimes get back to this project and add more stuff to it to enhance the compatability with everyones builds.

I'll see if that same contact I had before within Unity still works there and is still keen to resolving these Unity vs Newtonsoft.Json issues. This Unity Collections indirect dependency is quite annoying to work around, maybe we can come up with some good solution.

So to summarize, currently my package vs theirs are still competing, which is unoptimal for you Unity consumers. I do not see this change in the near future, but will make another effort in trying to resolve this.

Hi @jilleJr, thanks for a quick response.

The reason why I was really relying on your solution is because of the additional Unity Converters package which provides Vector3 and other Unity struct serializers which I need.

Well, yesterday I needed a solution quickly, so instead of messing with packages, I created my own NativeList implementation, so I could avoid using Unity Collections (> Performance Testing Package > Unity's Newtonsoft JSON) package completely.

After reading your message today that their package "should work allright as-is", I tried installing your conversion extension with Unity's Newtonsoft JSON, and.. Well, it works! I didn't really need to implement my own NativeList if I just tried replacing your Newtonsoft JSON package with Unity's. 🤦‍♂️ I just assumed there would be some dependencies between your 2 packages.

So, yes, your Unity Converters are compatible with Unity's Newtonsoft JSON package.


Unity's package problems are everywhere, and getting a new version of any gives me sweaty palms. Unity Collections' dependency on Performance package was not there from the start, it was introduced in a recent version. After posting this, I saw this post on the forums. I have a feeling they are trying to fix problems in a wrong way. I am not familiar with NuGet and its problems you mention, but maybe they should be 😄

I specifically ensured to not reference my own package in the converters package just because I know there are so many Newtonsoft.Json variants here and there around the internet. Glad that it actually found a use case :)

I'll edit the converters readme to be more clear that it hasn't a hard dependency.

Don't know if I can add anything to that forum thread, but I have not seen that thread before so thanks for shredding light on it. Reading christophera_unity's lengthy answer is awesome to hear that they still discuss the topic internally.

Hi, we had the same issue.
As @nothke thought, we expected dlls to not be duplicated.
However, I was confused at first because a duplicate error occurred.
So, we solved this by removing Newtonsoft.Json.dll.

Our env is below

Unity : 2020.3.21f1
Os : macOS Bigsur 11.6
Newtonsoft Version : 2.0.0

Our error code is like

스크린샷 2021-11-17 오전 10 53 37

How we solved this issue

First of all, we tried to remove Newtonsoft.Json.dll in
"Your Project Name"/Library/PackageCache/com.unity.nuget.newtonsoft-json@2.0.0/Runtime/Newtonsoft.Json.dll
But it didn't work.

Second, we tried to remove another Newtonsoft.Json.dll
We removed Newtonsoft.Json.dll and Newtonsoft.Json.dll.Meta in Assets/JsonDotNet/Assemblies/Standalone/Newtonsoft.Json.dll.

Then the error disappeared and it worked fine!

I wish you refer to that.