We'll probably have this eventually.

But in anticipation of greater assembly control in Unity 2017.2+, many months ago, we made it so that the Spine folders ("spine-unity", "spine-csharp") can live inside your Unity Project's "Plugins" folder.
This means it will be compiled with changes in the Plugin assembly instead of the main assembly. So it won't recompile every time you edit your "regular" game scripts.

The sideeffect is that you lose access to fields marked "internal".
All the fields and members you need are already public though.

You can do this with 3.4, 3.5 and 3.6. Just move BOTH spine-csharp and spine-unity into the Plugins folder.

For more info on special plugins folder, see:
https://docs.unity3d.com/Manual/SpecialFolders.html
https://docs.unity3d.com/Manual/ScriptCompileOrderFolders.html

Pharan,

I noticed an issue with compiling spine unity and spine csharp into DLLs separately.

Specifically, spine unity tries to access internal fields, which it cannot access.

For context, i am creating a headless server which needs skeleton data, so it needs csharp to extract gameplay data while spine-unity is only needed in the unity project which handles rendering.

I ended up just mass renaming 'internal' to 'public' to make the code work, but it seems like this breaks encapsulation hard.

Nevermind, both of those solutions were bad. I fixed it by opening AssemblyInfo.cs and adding:

[assembly: InternalsVisibleTo( "Assembly-CSharp" )]
[assembly: InternalsVisibleTo( "Assembly-CSharp-firstpass" )]
[assembly: InternalsVisibleTo( "Assembly-CSharp-Editor" )]
[assembly: InternalsVisibleTo( "Assembly-CSharp-Editor-firstpass" )]

Hi there!

Might I ask what is the state of this? The way Spine for unity works now we have to compile it on every recompilation of our own code, this is really slow and a lot of us would prefer a precompiled DLL.

I know that you are using .asmdef-files and I have all the dependencies specified in .asmdef files as well (with separate ones for runtime/editor just as you do). As often reported this doesn't really affect recompilation as much (if at all). And placing them in the Plugins-folder has no effect..

This is Unity's fault but we know that it works if we could just compile two DLL's instead of having two .asmdef-files.

I have tried to compile the DLL myself but I get errors from Unity complaining that what's in Spine's GUI-folder cannot be accessed from the DLL, and also the editors can't be loaded..

If you could please offer us a way to download a compiled DLL, or setup a Github repo allowing us to compile it ourselves (as suggested in this thread: http://esotericsoftware.com/forum/Precompiled-Libraries-6688).

Time to bite the bullet on this one Esoteric
Thanks a bunch!

It sounds bad that placing it in the Plugins folder no longer has any effect - may I ask which versions of the Spine runtime and Unity you are using?

I have filed an issue for this:
[unity] Precompiled dlls / compile time · #1276

I am using the latest version. Placing dependencies in the Plugins-folder yield little to no benefit for me.
Now, any word on how to compile that DLL?

For compiling dlls for Unity you can follow this reference:
https://docs.unity3d.com/Manual/UsingDLL.html

Also this Unity forum thread lists some hints:
https://forum.unity.com/threads/compiling-c-scripts-to-dll-files.318803/

Beware however, that most likely all script references will be lost, since the GUIDs all change when moving from scripts with .meta files to a dll containing the scripts. Restoring these references can be done by Editor scripting in the later Unity versions, otherwise you will have some manual work to do.

Or you simply wait for the issue, as mentioned in my last post above:
[unity] Precompiled dlls / compile time · #1276

2.5 years since the original request and we're still waiting for that compiled dll.

Would it be possible to release this runtime as a UPM package instead of a plugin - perhaps that could get Unity to understand that it shouldn't compile these files over and over again?

kloot wrote

2.5 years since the original request and we're still waiting for that compiled dll.

We are sorry for the long wait, but there have been some far more important topics that needed to be supported / addressed before. And unfortunately there still are.

kloot wrote

Would it be possible to release this runtime as a UPM package instead of a plugin - perhaps that could get Unity to understand that it shouldn't compile these files over and over again?

We have just released package.json files in the existing directory structure under Spine/package.json and Spine Examples/package.json (plus a necessary asmdef file for the Spine Examples directory). This way you should be able to use the packages via UPM or import it via the old unitypackage workflow, which we have to support for e.g. Unity 2017.1.

New unitypackages can be downloaded here as usual:
Spine Unity Download
We will release zip packages in addition to unitypackages at a later time as well.

Please let us know if this works for you and whether it improves the situation in terms of compile time as well.