koobas.hobune.stream
Monobehaviours & Editors with Inheritance across DLL boundaries don't load into Unity
Howdy unityAnswers community!
I'm currently spearheading an effort to refactor a bunch of code for our game and have run into a bit of a problem. We're separating a bunch of our code into DLLs, which includes Monobehaviours and Editors (and loose classes).
The issues which I'm running into seem to stem from inheritance across the DLL boundaries specifically for Monobehaviours, and any kind of inheritance for editors which don't directly inherit from UnityEditor.Editor. These scripts work exactly as intended if they are simply placed in the project hierarchy (in their respective folders of course). I've tried placing our DLLs in a plugins folder as well with no change in the script loading.
Below is a small slice which I've taken from our source which highlights the issues. We have a bunch of abstract base classes in our Core DLL which speak to low and mid-level subsystems. Concrete implementations of these classes in the game DLL are passed as their abstract implementations to these systems to be used.
When I look at the imported Monobehaviours under the Core DLL, the TriggerVolume script shows up, which is great however, when I navigate to the Game DLL, the UserCamera script does not show up, and neither does its entry the in the 'Add Component' menu (I have the proper attributes for the classes to show up in this list).
In what I believe to be possibly unrelated issue, it seems that DLLs which contain editors don't load correctly if they inherit from another class which inherits from UnityEditor.Editor. When I attempt to load the editor I get the error: 'Instance of NGUIIconControllerEditor couldn't be created because there is no script with that name. '. Removing the dependency on our intermediate Editor class allows the editor to load normally.
I was really confused that this was happening so after some investigation I was able to see what kind of 'workaround' would resolve the issue. Below is a UML diagram showing the separation of classes across the DLL boundaries as well as the object inheritance.
In the image below, you can see that I re-ordered the class inheritance so that there are no dependencies on the Core DLL's classes in the Game DLL. This allowed me to load the Monobehaviours and attach them to objects however, it completely breaks the functionality of our game. The broken dependency on BlackBirdEditor however, is something I may be able to live with but not being able to rely on abstract classes in the Core DLL seriously hinders our efforts to pursue this avenue of development.
I believe the issue may be with the way in which Unity parses the assemblies to figure out which classes are valid Monobehaviours and Editors however, I hope that there is an answer which doesn't involve submitting a bug report because in the 4 or so bug reports I've filed none have ever even been looked at :(
Thanks in advance!
Similar question here (but not solution): http://answers.unity3d.com/questions/240985/subclassed-monobehavior-in-external-dlls-not-recog.html
If anyone out there cares, we had Unity submit a partial fix for this bug which is present in 4.5.x with the limitation that DLLs which have inheritance like this must reside in the same folder.
This is good to know thanks! though this certainly seems like a strange limitation...
@GeraldOBBI, did you check to see if this works with generics? How about ScriptableObjects?
This is perfect thanks!!!
However, I do agree with @numberkruncer. Did they mention why that limitation had to be placed?
No, unfortunately they did not however they did mention that a proper fix would be much more difficult and likely address it further down the line.
I tested this on Unity 2017.3 and it looks like this problem is a history now. Prebuilt dlls can be placed in different folders and they can still contain classes with inherit from classes which are defined in other prebuilt dlls.
