The overall process is essentially the same as before except source files should be placed into a folder somewhere outside of the “assets” folder. A workflow can then be added using an npm script, a makefile, a shell script, a batch file, a gulp file, or whatever type of automation system that you prefer to use to initiate the building of the DLLs.
Built DLLs can then be copied into the “assets” folder structure so that they will be properly synchronized into Unity projects. This does mean that built DLLs should be committed to the package’s repository.
For instance, your package directory structure might look something like this (if using a similar directory structure to what uGUI uses):
your-package/ |-- assets/ | |-- Editor/ | | |-- MyEditorClassLibrary.dll # Editor DLL | | |-- MyEditorClassLibrary.dll.meta # EditorWindow's, etc. | |-- Standalone/ | | |-- MyRuntimeClassLibrary.dll # Standalone DLL with no editor goop! | | |-- MyRuntimeClassLibrary.dll.meta # MonoBehaviour's etc. | |-- Editor.meta | |-- Source.meta | |-- MyRuntimeClassLibrary.dll # Runtime DLL with editor-specifics. | |-- MyRuntimeClassLibrary.dll.meta # Like standalone with OnDrawGizmos. |-- source/ | |-- MyRuntimeClassLibrary/ | | |-- Properties/ | | | |-- AssemblyInfo.cs | | |-- MyBehaviourClass.cs | | |-- MyRuntimeClassLibrary.csproj | |-- MyEditorClassLibrary/ | | |-- Properties/ | | | |-- AssemblyInfo.cs | | |-- MyBehaviourClassEditor.cs | | |-- MyEditorClassLibrary.csproj | |-- MySolution.sln |-- Makefile |-- package.json |-- etc.
Note - It’s still important to include .meta files for the DLLs since this helps Unity to maintain links between scripts and assets.
For those interested in using DLLs to improve Unity’s “Plugins” directory build iteration times; I’ve heard rumors that there may be a better solution coming soon!