Unity did not regenerate the GUIDS when they forked my package (nothing to blame them for, as their fork is only meant for Unity's internal use anyway), and so now my package cannot coexist with theirs.
Then there's the DLL and namespace issue: Only one Newtonsoft.Json.dll assembly and only one Newtonsoft.Json namespace can be imported at the same time.
Motivation
Using Newtonsoft.Json in Unity is getting worse by the day. Leaks has to be plugged, and if this package could at least bring some better compatibility then that's nice.
Suggested solution
GUIDs needs to be regenerated. This could break things for some, but help others. Though choice.
Then regarding the assembly issue, we could either:
Force users to override references in their own assembly definitions (asmdef) to target the correct DLL when there's multiple ones loaded. Some good docs would have to be written for this.
-or- Make our assembly disable itself if it detects that Unity's package is loaded. Relying on Newtonsoft.Json v13 or v11 would not be possible, as Unity only ships v12, but at least it won't spam their console with errors. We could add a separate script that logs a nice warning to the user that "jilleJr's Newtonsoft.Json has been disabled". This would make us probably have to rely on higher Unity versions, so that's another big drawback.
-or- Rename the assembly ourselves. This should be deployed as a separate package though. Simply as Newtonsoft.Json2 or something. This is such a band-aid solution though...
Note: I, @jilleJr, will not fix either of the GUID nor assembly clash issues until I figure out a way I can solve both, because without both resolved there isn't any added value.
Description
The
com.unity.nuget.newtonsoft-jsonversion 2.0.0 and above has clashing GUIDs for the Unity assets, as mentioned by #139 and https://github.com/jilleJr/Newtonsoft.Json-for-Unity/discussions/135.Unity did not regenerate the GUIDS when they forked my package (nothing to blame them for, as their fork is only meant for Unity's internal use anyway), and so now my package cannot coexist with theirs.
Then there's the DLL and namespace issue: Only one Newtonsoft.Json.dll assembly and only one Newtonsoft.Json namespace can be imported at the same time.
Motivation
Using Newtonsoft.Json in Unity is getting worse by the day. Leaks has to be plugged, and if this package could at least bring some better compatibility then that's nice.
Suggested solution
GUIDs needs to be regenerated. This could break things for some, but help others. Though choice.
Then regarding the assembly issue, we could either:
Force users to override references in their own assembly definitions (asmdef) to target the correct DLL when there's multiple ones loaded. Some good docs would have to be written for this.
-or- Make our assembly disable itself if it detects that Unity's package is loaded. Relying on Newtonsoft.Json v13 or v11 would not be possible, as Unity only ships v12, but at least it won't spam their console with errors. We could add a separate script that logs a nice warning to the user that "jilleJr's Newtonsoft.Json has been disabled". This would make us probably have to rely on higher Unity versions, so that's another big drawback.
-or- Rename the assembly ourselves. This should be deployed as a separate package though. Simply as
Newtonsoft.Json2or something. This is such a band-aid solution though...Note: I, @jilleJr, will not fix either of the GUID nor assembly clash issues until I figure out a way I can solve both, because without both resolved there isn't any added value.