Question DLL conflicts in Two upm package.

I want to import two npm packages that both contain the same dll.
How can I resolve the conflict between the two dll's.

We really need npm to directly reference a nuget package to resolve
(System.Runtime.CompilerServices.Unsafe.dll
System.Memory.dll
System.Buffers.dll) and other dll conflict problems.

 

Typical conflicts https://github.com/SolidAlloy/ClassTypeReference-for-Unity/issues/25

 

Having the same issues.

These .dll conflicts alone forced my team to put our internal NPM repository efforts on hold.

Most of what I do on Unity involves internal tooling, API consumers, dev support stuff etc. and all depend on .dll's to some extent.

Some common examples

- AWS SDKs all depend on AWSSDK.Core.dll, so each package with AWS Features conflict on AWSSDK.Core.dll. One of our internal packages that used AWS .dll's was generating valid .upmconfig.toml files to connect to AWS CodeArtifact
- OpenAPI spec generated C# client, general public API consumers conflict on System.Threading.Tasks.Extensions, System.Net.Http, Newtonsoft.JSON, you know, the usual suspects
- Custom packet serializer / deserializer for a multiplayer game, shared between client and server conflict on System.Buffers, System.Memory usually found in Cysharp / neuecc packages for optimization purposes.

You can avoid conflicts between your own packages with enough care.
One option is to create packages that contain single .dll's for every .dll you will need and then use those .dll wrapper packages as dependencies, which you will have to maintain of course.
Another option is to rename every .dll so that they don't conflict (System.Memory.<PackageName>.dll), turn off the .dll's auto-reference property, and manually reference every dll used in the asmdef files.

Both of these options will still fail the moment you include a public UPM package that brings its own .dlls with auto-reference enabled, or when you import a .unitypackage SDK that doesn't even have an asmdef file.

Any help, clarifications on .dll management solutions would be appreciated. The best case scenario would be UPM capabilities for declaring isolated .dll s or nuget packages as UPM dependencies. OpenUPM is working on uplinking nuget packages but I think an official solution to avoid these conflicts would be better, most public packages do not depend on OpenUPM packages and just works with git.

 

I know necro bumping is normally a no no, but this has all the context with 100% relevance in 2022 still: Any update to this? Is there some sort of `ignore` feature for packages so things like dlls don't get registered?

Like for example, EVERY package uses Newtonsoft. Is there really no solution to 'choose' which dll you want to use, or what to do with it? How about a popup asking how we want to handle the conflict, then restart Unity?

 

I would love a feature to have preferences for which framework DLL to prioritize keeping, with fallback defaults (ranked choice) and per-package overrides

 

Is there a 'package ecosystem' team?

 

same problem, Newtonsoft and some other dll files in 2 instances and don't know how to relovle it.. is there a way to lock and incapsulate maybe inside package they are made for? because there some errors even if i delete one of files and packages use different versions of same dlls.