Question Multiple dlls with same name from packages

Hi!

I have a project with 2 dependencies, one is imported as an asset (placed in the Asset folder), and the other is a package (placed in the Packages folder), and both these dependencies include a few dlls which have the same name as the ones in the other dependency. The dlls are actually part of the same library, just different versions of it, and include both native and managed dlls. So the folder file system structure looks something like this:

Code (csharp):

1. - Assets
2.   - Dependency1
3.     - Plugins
4.       - x.dll (managed, version 2.0)
5.       - y.dll (native, version 2.0)
6. - Packages
7.   - Dependency2
8.     - Plugins
9.       - x.dll (managed, version 1.0)
10.       - y.dll (native, version 1.0)

So the error message I get when compiling is the usual "Multiple dlls with the same name...". I have tried removing the dlls from the "Dependency1" package, but since it requires a newer version I get compilation errors. If I remove the dlls from "Dependency2" they just get re-added the next time I start Unity (I guess it gets synced somehow with the package database).

Is there any way to solve this? I'm running out of ideas.

 

Try the following:
- Untick "Auto Reference" in your DLLs.
- Tick "Override References" in the assembly definitions that need to reference those plugins.
- Rename DLL files so that the names contain their version, e.g. "x_2.0.dll".
- Add respective DLLs to the references list of each assembly definition.

 

Hi, I am facing the same issue. Can you please tell me how to "Override References" in assembly as I see no checkbox on dll file

 

The "Override References" option is located in the Assembly Definition (.asmdef) files. You need to enable it when you want to use the .dll file in that assembly

 

Hey. I'm actually having this issue as well but in my case, two packages both import the same .dll.

So removing/renaming them is a bit tricky because it will only affect my local installation and not anybody else's in the team. Is there any good solution for this, other than moving one of the packages from Packages to Assets?

 

The only thing you can do from your end is to make one of the packages local. You don't need to move it to Assets, you only need to move the package folder from /Library/PackageCache to /Packages. This will make the package local and you will be able to remove the duplicate DLLs. You can also share this change with the team if the /Packages folder is included in the project repository.

It can be handled from the side of the packages authors though. Instead of including the DLLs into the package, they both need to declare them as dependencies in package.json and publish their packages to OpenUPM. Dependencies can be declared like this: https://github.com/favoyang/com.example.nuget-consumer/blob/master/package.json

More info on the NuGet dependencies in OpenUPM can be found here.

 

Right, forgot about local packages. But the solution is the same.

I'm not sure about the OpenUPM solution though. Would it resolve the issue if one package is using it locally and the other through OpenUPM? And if the developer also shares the package via .unityPackage and/or on Github wouldn't it require maintaining de facto two releases of the same package - one with .dlls and one without for UPM? What if the developer is using its own internal .dll in two different packages?

I believe the way would be just to rename the .dlls and override references as you've mentioned above. This will duplicate the .dll code in memory - at least I think it will - but if somebody is using Unity for a project a few MB of code won't make a difference probably.

 

The best case would be for both packages to be published through OpenUPM.

When one of the packages is local or installed through git - I'm not sure it would create a conflict, it needs to be tested. Before I would've said yes, but now we have the "Project Settings/Player/Assembly Version Validation" option, and if it's disabled, it might resolve the issue.

If you develop a package and want users to be able to install it through the git link instead of OpenUPM, you can provide the instruction to first install the NuGet packages your package is dependent upon, then install the main package. Yes, it's terrible that users have to install the dependencies manually, but the same goes for other package dependencies (e.g. if you depend on another package published on GitHub).

If the .dll is an internal one, developed by the package author, the author can create a third "Core" package where they will put all the code shared between two packages, including the shared .dll. This Core package will then become a dependency of their other packages.

 

I had an issue in build while renaming a Dll's dep :
A.dll depends on B.dll, they both are duplicated so had to rename them to A.MyDLL.dll and B.MyDLL.dll, it works in editor but in build I'll have another dll that fail to find B.dll.

I believe I should find a way to rename the dll in builds to their original way with some sort of build callback script. (I renamed them by hand in the build and it worked)