[SOLVED] DLL Dependency Causes Problems in Reading MonoBehaviour From DLL

This is a pretty simple problem, and likely doesn't have a solution, but I figured I'd give it a shot anyways.

I just discovered that if I compile a set of scripts into a DLL, which includes a MonoBehaviour-derived base class I want to use, then build a second DLL (having the first DLL as a dependency, so it loads just fine), which includes a class that derives from the aforementioned base class, the derived class won't be recognized by Unity as a MonoBehaviour, and thus won't be able to be attached to GameObjects in the scene.

In other words, putting a class "BaseClass : MonoBehaviour { }" in Base.DLL, I'll be able to attach Base to any object in the project, but if I create a second DLL that contains "DerivedClass : BaseClass { }", called Derived.DLL, then Derived won't be recognized as a MonoBehaviour. Well, it's recognized as a MonoBehaviour within scripts, but not within the inspector, because it's not shown in the list of MonoBehaviour classes under the DLL rollout and isn't attachable to any objects in the scene.

If DerivedClass is, instead, defined in a loose script, then it functions fine, even if deriving from a class within a DLL- it's only when it's compiled into a separate DLL that it ceases to function properly as a MonoBehaviour.

Is there some reasoning for this that I'm overlooking, or am I just screwed?

 

Two days later, I finally managed to get the exact combination of words that led to search results in the bug tracker. In case anyone's curious, this was apparently a big issue until 4.5, when Unity coded a DLL inheritance check to fix this bug with the editor (not exactly a bug, but more of a system limitation involving serialization). The check only runs with DLLs that are placed in the same directory with eachother though.

In my previous example, both Base.DLL and Derived.DLL must be in the same directory, and then the classes in Derived.DLL (derived from classes in Base.DLL, which are themselves derived from MonoBehaviour) will just magically show up and be usable. This is very cute, and is still working in 5.5.

One would expect that a more versatile solution would've been made by now, so much later, but I'll take what I can get.

 

I just ran into this myself, thanks for the excellent detective work.

"The check only runs with DLLs that are placed in the same directory with eachother though."

Would be nice if this check could be expanded to DLLs that share the same parent folder as it's quite restricting otherwise.

 

No problem, it's nice to see that it helped someone out. It would definitely be nice if they expanded this, as it's quite annoying, but I think it's just a symptom of a far greater issue.

The primary reason that I prefer using Unreal over Unity now is because of how much easier it is to organize things properly, even when using assets that were created by other authors. In Unity, we have directories that we can't move because they're "special" and their contents are treated differently, some commercial assets have to be in the root directory while others can be moved around freely, and we have functions in classes that have to be given specific names so that they can be magically accessed using reflection, rather than simply overriding base virtual functions or meeting the contract for a given interface.

In other words, everything is too rigid. I absolutely abhor the fact that asset files can't be organized properly and any project that uses more than 1 or 2 purchases from the Asset store are an organizational mess (with no way at all to fix it). Worse, they keep updating Unity to increase support for flashy things like VR, while the core program remains half-broken and restrictive as hell. We don't even have a timeline editor (sequential event management) without paying for one.

Never mind all of that though- my point was that while I'd like to see support for DLL dependencies expanded, I think they need to just overhaul the entire system rather than going out of their way to specifically expand the functionality of a band-aid patch. *shrugs*