koobas.hobune.stream
Classes that inherit UIBehaviour in a DLL no longer visible in Unity editor.
I recently upgraded to Unity 2019.2 from the last version of Unity 2018, and see that any of our classes that inherit from a UIBehaviour are no longer visible as a component to add, and that all references to them have broken. By selecting the DLL, I can see that they no longer show up as possible components, but others that do not inherit UIBehaviour do show up.
I believe I have properly added the Unity DLLs to our library project, seeing as everything compiles, but I theorize that's still the issue. In Unity 2018, you only needed UnityEngine (and UnityEditor for editor DLLs). In 2019, it appears you need a ton more. I couldn't find any recent documentation on the subject, so I eventually stumbled upon the "solution" myself.
I have referenced all DLLs from C:\Program Files\Unity\Hub\Editor\2019.2.1f1\Editor\Data\Managed\UnityEngine except for the Unity.Cecil dlls and Unity.Legacy.NRefactory.dll.
Some of the libraries that have been in previous versions of Unity are being moved to external packages. You can include them in your project by opening the Package Manager (Window --> Package Manager) and selecting the packages you want to include. Unity UI is one of those packages.
As the Unity ecosystem grows and evolves, moving stuff to optional external modules is probably a good strategy, but I often feel disappointed that the Unity documentation does not keep up. As features get migrated to external packages, the documentation needs to be updated to say where they went. When objects or interfaces become deprecated, the documentation needs to say more than just "[deprecated]". It should say what it is being replaced with, or how to work around the absence of the feature. I have suggest that more than once in the little suggestion box at the bottom of each doc page. I like that feedback is solicited. I hope it gets looked at.
Yes, we referenced the UnityEngine.UI.dll that was built by a Unity project, but it still has the same issue.
$$anonymous$$y theory is that it thinks I have two of every class in UnityEngine.UI.dll. One from my library referencing a UnityEngine.UI.dll, and one from the project, where it built its own UnityEngine.UI.dll, despite them being technically the same DLL. I believe this is why I can't add a class from my library that inherits UIBehaviour, I sees that as a different UIBehaviour than the one from the UI package.
Yes, you're right, the documentation about creating your DLLs hasn't changed for at least five years probably. It'd old enough that they don't speak of how to reference UnityEngine.UI.dll before it was a package.
I surely cannot be the only person. Surely there are hundreds of people with external libraries. We have a generic Unity library we've built that's used on many Unity projects. How is it supposed to be done? This is a game-stopper of a problem. We're downgrading because of this issue.
@DrZoop You can fix it like this. First remove unity ui from package manager(also textmesh pro, it depends on unity ui), then import unityengine.ui.dll and your owen dll into your unity project. If you have some ui prefabs which create by old version unity, missing scripts such as button, image, etc. Change old scripts's guid in those prefabs to new guid that generated by your imported unityengine.ui.dll. It may be a unity bug. Hope 2019 lts version will fix it.
