koobas.hobune.stream
Issues with UnityEngine.UI when referenced in a class library, since Unity 2019
In my work environment we have the practice to develop custom unity functionality as dotnet class libraries. For the purpose of this, we first create a standard .NET class library project. Then we add the unity engine dlls as references to the project, like this:
<ItemGroup>
<Reference Include="UnityEngine.UI">
<HintPath>path\to\UnityEngine.UI.dll</HintPath>
<Private>false</Private>
</Reference>
</ItemGroup>
Here, path\to\UnityEngine.UI.dll will be a custom folder where we put Unity dlls to be used by our library projects. The dlls in that folder are the same as the ones found in the Library\ScriptAssemblies subfolder of a unity project. Once we decide to move to a newer version of unity , we update the dlls accordingly, by creating an empty Unity project with the new version of unity we want to use, and then copy the dlls. This has worked well so far, until Unity 2019 came along.
When we upgraded to Unity 2019, we experience issues with the UnityEngine.UI.dll. The reference is detected by both Visual Studio and Rider, and syntax highlighting in Visual Studio does not report any error. However, when we attempt to build a library which requires classes from UnityEngine.UI we receive build errors, mostly for the following types:
UnityEngine.UI.GraphicRaycasterUnityEngine.UI.TextUnityEngine.EventSystems.EventSystem(this class is suposed to be in theUnityEngine.UI.dllregardless of the different namespace).
We usually have errors like this:
error CS0246: The type or namespace name 'Text' could not be found (are you missing a using directive or an assembly reference?
or
error CS0234: The type or namespace name 'UI' does not exist in the namespace 'UnityEngine' (are you missing an assembly reference?)
When we reference the dlls from Unity 2018.3.2 (our former unity version) we did not experience any issues).
How can we overcome this problem? My wild guess is that it has something to do with the new assembly definition changes. Could the assembly definition approach be used for developing libraries as standalone dlls? In general, how should we address the issue if we want to be up to date with unity development? At this stage, we have quite a huge codebase of libraries, and I'd appreciate solutions that would not introduce radical changes in our project model, if possible. Reverting to older unity version is not an option for us, as we need to be able to stay in par at least with the stable releases of unity.
Thanks in advance
Very interested by this answer as well! We ship our tools internally as .dlls and it seems like since 2019.1 it has become very difficult to add UnityEngine.UI to a VS project.
If I have both UnityEngine and UnityEngine.UI imported in a visual studio solution, it asks for other assemblies to be linked : UnityEngine.CoreModule, netstandard, ... but if you reference these dlls you end up with duplicate symbols from UnityEngine & these assemblies.
Any solution from the Unity team?
@Bibzball indeed, I've been there and I feel you for the duplicate errors. I have a solution for the duplicate files -- you need not include all the UnityEngine*$$anonymous$$odule.dll, instead reference UnityEngine.dll which is located in ${UnityInstallationPath}\Data\$$anonymous$$anaged\UnityEngine.dll. This file should be relatively large -- about 3-4 $$anonymous$$B, and it is a "merged" version of all the UnityEngine.*$$anonymous$$odule.dll files. I use that particular dll for my library projects. However, an analogue of UnityEngine.UI.dll is not to be found in the Unity installation directory, that dll is dynamically created for a unity project, and is placed in ${UnityProject}\Library\ScripAssemblies\UnityEngine.UI.dll. Snce Unity 2019 this dll has the issue this thread is about.
Thanks for your answer @ivaylo5ev . Glad to see that I came to the same conclusion while investigating. Hope someone from Unity answers about UnityEngine.UI.dll
