Conflict between Asset's Newtonsoft and PackageManager's Newtonsoft

Unity Engine
21

I’ve checked with the team and there isn’t any progress at present. The workaround remains the same:

3 Likes
22

@UnityMaru Today i tried upgrading my project from 2018.4.22 to 2019.4.21f1. And i was also prompted for asset database version change to latest and i accepted that. Now i get multiple errors, to name few.

PrecompiledAssemblyException: Multiple precompiled assemblies with the same name Google.VersionHandler.dll included or the current platform. Only one assembly with the same name is allowed per platform. Assembly paths:
Assets/ExternalDependencyManager/Editor/Google.VersionHandler.dll
/home/bhupi/Unity projects/Sample/Sample1/Library/PackageCache/com.google.external-dependency-manager@1.2.153/ExternalDependencyManager/Editor/Google.VersionHandler.dll

PrecompiledAssemblyException: Multiple precompiled assemblies with the same name Google.VersionHandler.dll included or the current platform. Only one assembly with the same name is allowed per platform. Assembly paths:
Assets/ExternalDependencyManager/Editor/Google.VersionHandler.dll
/home/bhupi/Unity projects/Sample/Sample1/Library/PackageCache/com.google.external-dependency-manager@1.2.153/ExternalDependencyManager/Editor/Google.VersionHandler.dll

AssetImporter is referencing an asset from the previous import. This should not happen.

23

Hm, I’ve chat to the team about this and a bug report would be handy to look into this. Are you able to submit one for me and let me know of the ID?

24

I finally moved to 2019.4.21f1 successfully and hence cannot reproduce it. But it seemed that it was creating another plugin folder with small “p” where i already had one with big “P” and i think it was happening because it could not find one of the mentioned plugin folder, unity assumed that the dependent libraries are not available and hence use to make a duplicate copy from “/Library/PackageCache/”. So finally i deleted existing plugin folder and let it re-import completely from the PackageCache, and finally the migration was successful.

Would this info be sufficient for you ?

25

Can anyone explain why renaming a DLL works to solve the conflicts issue?

(maybe @UnityMaru can explain?)

26

An actual bug report seems like the only thing that would help at this point. If you can no longer repro, then this doesn’t seem a sufficient lead for an investigation to be done.

Your mention of a plugin folder with lowercase and uppercase P does not seem relevant with the error messages you previously posted, which pointed to the problem being that Google’s “ExternalDependencyManager” was present twice in the project, once under Assets (probably imported from a .unitypackage/Asset Store package) and once under Packages (added through UPM).

I’m not sure that changing the casing of a DLL name solves a DLL conflict, but I know the ScriptingPipeline uses assembly (DLL) names to create some internal “map” and will bork on duplicate DLL names. This is actually what was happening here. But even with different names, if two versions of a DLL are included in a project, it could (and would typically) result in compilation errors because two different DLLs define the same symbols (namespaces and class names) and the compiler doesn’t know which one to use.

So it wasn’t just a renaming thing. In fact, I think the first user’s problem got solved without the user realizing, and their comment about the P/p change confused things into think that this was the solution.

1 Like
27

I upgraded to 2021.1.9f1 today and this is now an issue for me. Its time to make a stand on Json.Net. Stand on one side of the road or the other. Microsoft had the exact same problem and built System.Text.Json with help from NewtonSoft. Go left or right and let your developers know what your doing so we all can use Json without this headache.

28

Holly smokes…after looking at GIT diffs it seems there is a change to package-lock.json which describes dependencies.

      "com.unity.collab-proxy": {
      "version": "1.5.7",
      "depth": 0,
      "source": "registry",
      "dependencies": {
        "com.unity.nuget.newtonsoft-json": "2.0.0"
      },
      "url": "https://packages.unity.com"
    },

We bring in another JSON.Net package. and this is where the problems lie.
When I look up the details on this package you find it is not supported… (Ouch)
https://docs.unity3d.com/Packages/com.unity.nuget.newtonsoft-json@2.0/manual/index.html

So, I can’t add this independently and the documentation says I shouldn’t use it.
This is a package intended for internal Unity Development Projects and as such this package is not supported. Use at your own risk.

Unity- Its time to put on the big boy pants and get your dependencies in order!
If your coders need newtonsoft just make it an official package and support the darn thing.
So many of us use this, it would really make sense to include it.
Either use something different internally that doesn’t conflict or make it available so we can all use it!

I need to get my code working and the only solution is removing parentElement’s implementation of newtonsoft.
How long will it be until this dependency is removed and my code again fails due to lack of newtonsoft?

I am also not sure how platform compatible com.unity.nuget.newtonsoft-json is?
parentElements package goes to all platforms.

2 Likes
29

@cgrow67_1 The temporary solution may be removing Version Control (Unity - Manual: Version Control) via Package Manager.

3 Likes
30

They probably don’t support it, because they are planning to remove it as a dependency, eventually. Imagine if they start to support it and then they rip it out. This way at least you know that you shouldn’t use it.
Or you can start using it, when you update Unity packages you will be notified about the missing lib and you can add it. And you probably will want to switch to System.Text.Json too, when it becomes available.

It’s smaller deal than it seems. It’s not like breaks at users’, it breaks when you change your project.

Edit:
BTW, apparently Unity is indecisive about this one. In 2021.2a17:

1 Like
31

Solution that worked for me:

  • Copy Library/PackageCache/com.unity.nuget.newtonsoft-json to Packages/
  • Remove com.unity.nuget.newtonsoft-json from packages-lock.json
  • Delete or copy replacement Newtonsoft.Json.dll files into Packages/com.unity.nuget.newtonsoft-json

This basically hard sets com.unity.nuget.newtonsoft-json in your project Packages/ dir, so Unity doesn’t pull down it’s own version of the dlls. This then allows you to override them by pasting the exact version in you want.

3 Likes
32

This is the best solution if your not using collab… very simple.

Newtonsoft.Json is a really popular package so inserting it by default into our projects feels like a dirty trick…
In Visual Studio when you look at reference properties there is an Alias property you can use to fix stuff like this.
Possibly packages should have something like this where you could modify the namespace when its brought into a project?

Another option would be to have a Newtonsoft.Json package that we can all share.
I could use it, apparently your team needs it and I’m sure there are others that would move to using it.

Please…

2 Likes
33

Delete your Project\Library\PackageCache contents. Then re build the project without this dll/pachage confilcts.

34

I hit this issue and resolved it by removing version control from my project.

5 Likes
35

This is really annoying. All the solutions posted here aren’t working for me. I needed the jobs package and off goes my sanity. Lovely.

36

First time? Personally, at this point I’ve probably spent more time debugging buggy Unity than my actual project. With each new update, Unity seems to release more bugs than bugs life, and more glitches in its core systems than Metal arms: glitch in the system. Terrible.

1 Like
37

In your case, a bug report is probably going to be worthwhile if you’ve tried all the workarounds.

Let me know the ID of it so i can flag with the team directly.

38

Perfection, thanks for posting

39

Holy crap… This issue is still isn’t fixed and internal version of Newtonsoft.Json breaks completely plugins that were compiled with specific version that don’t fit with supplied by Unity.
The only solution is to completely remove collab package… Why it isn’t fixed yet? That’s almost ONE year old already…

P.S. Unity version 2021.1.15f1, using Nethereum library which was builded using specific version of Newtonsoft.Json.

1 Like
40

Wow, not only is this an issue with custom packages, many of the unity packages themselves, when imported together in the same project, are giving this issue. I’m surprised that this bug is still a thing.

Solutions posted here are not really helpful, like deleting version control, etc. What happens when we delete the affecting files from PackageCache, and then we need to resolve the Package Manager dependencies? Go and delete them manually every time? This is really annoying.

1 Like