Unity 2017.2 Assembly Definition Files

From Unity 2017.2 beta Release Notes:
Editor: Added assembly definition files feature for script compilation pipeline in the editor. Allows you to define your own managed assemblies based upon scripts inside a folder. By splitting your project's scripts into multiple assemblies, script compilation times in the editor can be greatly reduced. Note that the latest version of Visual Studio Tools for Unity is required for this feature to work with solution and project generation for Visual Studio.
We make the Spine runtimes source-available so that you can read, adapt or remove parts from the code you don't need.
Up until Unity 2017.1, if you place your Spine runtime code in Unity's special folder named Plugins, it will compile the Spine runtime code with your game's Plugins assembly. This means you could work on your game code, and your plugins code separately, and they will also compile separately, and only the assembly that changed needs to recompile.

With 2017.2, you will be able to define more assemblies for separate compilation.
We will likely provide the assembly definition files with the unitypackage once Unity 2017.2 is released (sometime soon).
To start and to keep setup simple, we'll likely be putting all of spine-csharp and spine-unity (and all included modules) into one assembly.

If your existing code uses some fields or methods that are marked internal because they were all originally in your game's main assembly, this may force you to take stock of your code regarding how your classes and functionality are organized. Deeply-Spine-integrated functionality may need to be included in this new Spine assembly.

However, over the past several months, we have prepared for this change by providing and recommending using or caching public properties over internal fields.
If you feel like your code is reasonably detached from Spine's internal systems but you still need to use that internal method, property or field, we would appreciate your feedback and we'll figure out how to expose it in ways that can make sense for everyone.


Seems like there have been changes in the scheme though we never got to arranging it since the feature didn't make 2017.2

I've been reading up on it the past few weeks. One point seems like the recommendation is to "use it for everything or don't use it at all".
We'll have to see how it interacts with the Plugins folder, which would be the plausible "don't use it at all" alternative.

Having disconnected editor folders (as in the Modules folder) may cause some problems. We'll see how best to address it without making things too complicated to remove.
User avatar

Posts: 4542


I am currently experimenting with manually adding Assembly Definition Files to our external assets, and would like to ask — no matter whether you decide to add assembly definitions officially or not, could you please group all Editor scripts together in one Editor folder, rather than having several Editor spread across the hierarchy?

Editor scripts have to be in a separate assembly, and by organizing them all in a single folder, users can just simply create two Assembly Definition files, one for Editor, another for the rest of the asset and be done with it.
Posts: 3

Return to Unity