koobas.hobune.stream
Components Inside A DLL
I'm in the process of developing a library for use with third-party Unity projects. Ideally, I'd like to have certain MonoBehaviours which are defined within that library (a compiled DLL) and then exposed within Unity. But, Unity doesn't seem to pick up on the existence of MonoBehaviours inside a DLL (even if I try to add them explicitly through an editor script).
The workaround I've found so far is to subclass my library MonoBehaviour in a script file, and add the subclass as a component. This seems to work so far, but is there a way to expose the library class to the editor directly?
From 3.0 you can use monobehaviours from dlls. The dll need to be added to any folder named Plugins inside the Assets folder.
Once there you can use the Project window at the Unity Editor to explore the DLL contents and drag and drop the monobehavior into any game object.
It works just fine!
(As of Unity 3.5.6) It works unless you want a generic base class. In scripts, I can have $$anonymous$$yBaseComponent<T> : $$anonymous$$onoBehaviour and $$anonymous$$yDerivedComponent : $$anonymous$$yBaseComponent<string>, but in a DLL this doesn't work. (Yup, this is a bug.)
(As of Unity 4.3.1) It works, but there is a Unity Editor bug that prevents you from having a component in one DLL that derives from a component base class in a different DLL.
In 4.6.1f1 the bug still exists. I cannot inherit from a class from an extern DLL that inherits from $$anonymous$$onoBahiour. When I add the reference it works until I simulate the game. Also I created some scripts in my own external library but I cannot browse them in the project explorer.
{EDIT: this is old information for Unity 2.x} Unity does not yet support MonoBehaviours inside a DLL. See the comments on this blog post by AngryAnt. He mentions:
Unity unfortunately does not yet support MonoBehaviours and ScriptableObjects in external assemblies. Remember that your external code is still not a first class citizen in your Unity runtime, but an external assembly
As AngryAnt himself is a Unity employee, I expect that's coming from the source.
That blog entry is actually quite interesting as well... Thanks AngryAnt, wherever you are.
Unfortunately not - but I think that would be very worthwhile feature request. Currently, Unity only keeps "assets" in the project pane; and MonoBehaviours are only considered "assets" when they exist as actual files. Another limitation you have there is that MonoBehaviours can't be put into namespaces (they must always exist in the root namespace).
For your use case, I think the ideal solution would be if Unity could look into DLLs and search for anything subclassing "MonoBehaviour" and then allow you to "expand" the DLL (it must be in your Assets/-folder anyways). Then, it could also use the namespace hierarchy you provide in the DLL, so if you have, for instance "Jormugandr.Scripts.TheUberCharacterController", in your DLL JromungandrProTools.dll, and the user has put this into Assets/External/JromungandrProTools.dll, Unity could show this in the project pane as follows:
External
+ JromungandrProTools(.dll)
+ Jromungandr
+ Scripts
+ TheUberCharacterController
I'd love to have that - but keep in mind: This is just a potential solution that should be filed as feature request at: Unity Feedback
EDIT 1: With that in place, you could not drag'n'drop TheUberCharacterController onto any game object you wish.
EDIT 2: Ah, I just found out that there already is a feature request for this, so go, vote it up ;-) ... see Scripting: Ability to define MonoBehaviour in DLLs
Currently in version 3.4 you can create dlls with monodevelop (inclided) and frankly it's easy, it is also possible to make a dll with code for editor.
Does the code for editor then need the resulting dll in an Editor folder?
Yes, any scripts in Editor folders should be moved into a DLL which itself goes in an Editor folder. (e.g. Plugins/Editor)
