Hi. I’m using a package which deps on com.unity.collections@0.5.1-preview.11. Unfortunately this package includes System.Runtime.CompilerServices.Unsafe.dll which conflicts with the same DLL in Grpc’s unitypackage. I found that if I manually delete the duplicate (and older) DLL from com.unity.collections in the package cache, I can work around the issue, but every time the package sync’s I am forced to play wack-a-mole with the file.
Is there any suggested methodology to control multiple DLLs of the same name but different versions, or filters which files specific packages sync? I could delete the duplicate DLL from my pull of Grpc, which saves the automatic re-sync problem, but the DLL provided in com.unity.collections@0.5.1-preview.11 is missing some methods required.
Any other suggestions would be greatly appreciated.
A workaround for this issue for the user is to embed the package com.unity.collections in your project, which you can then delete the duplicated DLL and it should not be added again into the package. The downside of embedding is that updating the embedded package will have to be done manually, but at least this could alleviate your current issue.
About DLL included in packages, DLLs are not manager by Package Manager, other systems in Unity are the one that deal with them. Unfortunately we currently don’t have a mechanism in the Package Manager to solve a problem where two DLL with different versions are present in the project, we might have it in the future as this is a problem that keeps coming back to us.
Is there any way to have Packages built hermetically such that DLLs in a built package are completely hidden from other built packages? Allowing support for multiple versions of the same DLL?
Have you considered embedding the com.unity.collections package in your project, and removing the DLL from it? I understand that this is not as practical as just “having it work”, but currently it’s not possible to have multiple versions of the same asset or DLL side-by-side in the project due to how the asset, compilation and build pipelines work.
Yup, this is the current workaround we are using. I was hoping there was a way to hide the DLL (and other deps) in one package from other packages or the main project. I hope a cleaner solution will be available in the future.
Embedding the package and removing the DLLs doesn’t work in our case since we get the different versions of the DLLs from transitive and libraries built into other libraries.
My research has shown that the project files generated from the assembly references seem to be able to reference the correct dlls but Unity is not able to somehow.
The two plugins with a simple script and assembly references are in the package folder (plugin test (+ plugin test 2))
I’ve build a test project with two dlls using different versions in case you want to test this.
The screenshots show rider resolving the correct dlls.
