Question Conflict with existing Newtonsoft.JSON package

We already have Newtonsoft.Json in our project, when adding "Remote config" from the UPM UI, i am getting conflicts on all types from Newtonsoft.Json since we already have it, and the package references another copy of it as well.

I could only find 1 post in this forum regarding this issue: https://forum.unity.com/threads/dependency-on-newtonsoft-json.814128/#post-5398014

Any way to easily work around this issue ?

 

I had a similar issue if I recall, and I believe I used this https://assetstore.unity.com/packages/tools/input-management/json-net-for-unity-11347. Otherwise, can you provide your steps to install Newtonsoft.Json on a new project so we can attempt to reproduce here?

 

I have Newtonsoft.JSON for a long time in our project. It was imported as a UnityPackage from the asset store.
It is located in some folder in our project.

When importing the remote config package, i am getting conflicts.

 

Please provide steps to reproduce on a new project and the URL of the asset to use.

 

I reported this as a bug so i can include our copy of JSON.NET (didn't want to share it here).

(Case 1268302) Remote config package conflicts with Newtonsoft.JSON

 

Can you elaborate, your copy? Where did you install it from, did you modify it? I read the bug report, but I need steps to reproduce on a new project.

 

Our project is running for a few years now, we installed it from the asset store (bought it).

The location is not the original one, and we didnt modify it.

 

Can you provide the Asset Store link? Sorry I didn't follow what you meant by original location

 

I believe it is this one: https://assetstore.unity.com/packages/tools/input-management/json-net-for-unity-11347

 

What version of Unity are you using? In the meantime, you should be able to use fully qualified namespace names to keep them separate.

 

We are using Unity 2018.4.

What do you mean by fully qualified namespace? u mean modify our version of JSON.NET to make its namespace different from the one Unity is using?

I think the other way around is better - Unity should modify the package. Don't make me do the hard work myself...

 

No, when you make the call, put in the fully qualified name of the method, with the namespace. Yes, we will look into it, you would need to wait for a future release however. Please show your Using statement, and a representative method call. I'll show you how to add the FQN.

 

the fully qualified name will not work. it's not the call that is problematic, its the fact that the same classes are being compiled twice in 2 separate assemblies, which is not possible.

Is there any workaround for this so we can try remote config? so far i haven't found one.

 

It is suggested that you remove one Newtonsoft or the other (the Newtonsoft package in Remote Config OR the existing one in the project), and then re-point the broken references to the version you choose to keep

 

Hey guys,
I wont be able to remove the existing Newtonsoft in the project and I just couldn't figure out how to remove the Newtonsoft from remote config. Is there a way to remove the Newtonsoft that is getting added because of adding the remote config package ?

Thanks,
Naveen Thomas

 

Can you provide additional details? Why are you not able to remove the existing package? Once I have a few more details, I can check with engineering. Perhaps share some screenshots and any errors that you receive.

 

Remote Config shouldn't ship with its own copy of Newtonsoft (a very common library used by many teams) - it should declare a dependency on the hosted Newtonsoft package, so that teams can use that package the same way Remote Config uses that package, assuming it should use something as heavy as Newtonsoft at all!

Why can't remote config use the built in JsonUtility from Unity itself? Because it's too primitive? If so, that's why many games already have the full Newtonsoft project in their projects, and you will run into this conflict repeatedly. Maybe JsonUtility should be improved.

Either way, bundling your own *copy* of something many teams already have is inviting conflicts just as @liortal reported here.

 

Hey Jeff,

It's not that we cant remove the existing Newtonsoft, Its just that we wish we had an option to remove the newly added Newtonsoft from RemoteConfig.

The existing Newtonsoft that we have in the project is part of our framework and we would not want to remove that at this point of time in our development. It will be great if we can remove the new Newtonsoft that gets added to the project again when we are experimenting with the RemoteConfig.

Thanks,
Naveen Thomas

 

Understood on the concerns mentioned here, it makes sense. I will pass this along to engineering.

 

any update on this?

 

No, I've mentioned it a few times here