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 DLL conflicts with Cysharp packages · Issue #25 · SolidAlloy/ClassTypeReference-for-Unity · GitHub
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
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..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’ve had a chat with the team about this.
Basically we don’t see this so much as a Package Manager issue but rather a “package ecosystem” issue. Bundling 3rd-party DLLs in a package doesn’t play nice with Unity because the underlying platform cannot load two versions side-by-side. The only real solution for now is wrapping DLLs in your own packages.
As for other people’s packages or .unitypackage SDKs, the only workaround for now is to fix those once they get into your project to avoid the conflicts. To fix a UPM package, you would first need to embed it in your project to make it editable (Unity - Scripting API: PackageManager.Client.Embed)
We’re not trying to say there isn’t a problem here 
This definitely sounds painful and we understand their frustration but this isn’t something that the Package Manager team will be addressing directly for now.
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.
To those asking here - yes there is a package ecosystem team and yes this and surrounding package functionality is being actively discussed at time of writing. We have a large body of work to improve the experience around packages which includes scoped registries - someone from the team is also tasked with circling back to this thread and following up too.