- Home /
Which is the easiest technique to produce deliverable editor scripts with closed source code?
Which is the easiest technique to produce deliverable editor scripts with closed source code?
I'm looking at the direction of writing a DLL referencing UnityEditor namespace, but I'm not sure exactly where to start so that it works as a regular editor script would. And more, how to avoid DllImport[]s so to retain Unity free compatibility.
Answer by mlapin · Mar 10, 2010 at 10:52 PM
Thank you Ricardo for the reply!
After getting deeper into the subject, perhaps I got the directions I needed:
To mix both editor scripts and .NET plugins, which supposedly work both on free and Pro. I wasn't aware it was possible this way! I got misdirected by the assumption that only Pro support plugins, but that refers to C/C++ plugins only.
Regular editor scripts would implement MonoBehaviour for initialization and interfacing with the editor, namely overloading OnGUI, OnSceneGUI, OnInspectorGUI and adding MenuItems etc.
On the other hand, external .NET code must have access to UnityEditor namespace. Classes from the plugin will be referenced from the editor scripts and perform core functionality.
--update:
That works indeed!
Sometimes contractual policy do not allow us from sharing source code! Or one may have his/hers own reasons to decide to do so.
Hence, I believe this is the easiest technique to share closed source editor code:
1- Code in JavaScript or C# the editor scripts that will be left as source code inside Assets/Editor folder and which do implement MonoBehaviour.
2- Code in a separate C# file the core functionality classes which you would like to compile into a .NET plugin. Declare everything inside your own namespace.
3- I used MonoDevelop + Mono Runtime to compile my .NET plugin. To access UnityEngine and UnityEditor namespaces from inside your plugin, you must reference UnityEngine.dll and UnityEditor.dll. MonoDevelop allows you to easily add these references through its visual interface. Both Unity dlls can be found inside Unity.app/Contents/Frameworks (I haven't tested that on Windows). I did not check the need for UnityEngine-Debug.dll - had never noticed that before...
4- Remember to state 'using UnityEngine' and 'using UnityEditor' at the beginning of your plugin code.
5- If everything went right, you are now able to compile your library as a dll.
6- Copy your .NET plugin .dll to anywhere inside your Unity project, ie. inside Assets folder.
7- From JavaScript or C# you can write 'import/using MyNamespace' and from this point on all classes of the respective namespace will be directly available. You can, for instance, call a MyClass.Update() from inside your OnGUI() code, making your plugin to breath!
The code for my first test plugin looks like this:
using System; using UnityEditor;
namespace AdmRuntime { public class MyClass {
public MyClass ()
{
}
public String Test ()
{
String path = EditorUtility.SaveFolderPanel ("My first test!", "", "");
return path;
}
}
}
Thanks Unity team for making things so flexible and easy! Thanks AngryAnt for the insight -did you notice? ;)- that came from your sweet Behave project.
Best regards,
Mario
Answer by Ricardo · Mar 10, 2010 at 03:29 PM
Unity does not yet support MonoBehaviours inside a dll (there's a request for it that you can upvote) so I'd be surprised if it were to support pre-packaged editor code. Bear in mind that Unity is even very specific about in which directory the editor code is placed.
If anyone has more information, do let me know if this is inaccurate.