Reducing Compile/Refresh Time in Editor

I've tried to do some research into reducing build times, but it's a bit difficult with a lot of the information being years old and some things most likely being fairly different with Unity 5.

So I thought I would just ask you guys what tips and techniques you use to make larger projects become manageable and less painful to work with? I'm currently looking at around 15 seconds for Unity to refresh code changes, and it's really killing me.

 

There's always pro...

 

Just sent you a PM regarding precompiling JSON .NET. Here is something I do with other code... I like to use precompiled DLLs as much as possible. One thing you can do is create a solution and add your logic / etc projects. Configure your other projects to build to the /assets folder instead of /bin. You can then build from visual studio right into your /assets (or wherever) folder and load those DLLs into Unity. This will result in a fair amount of your code being precompiled. You can build those in Debug mode, load symbols if necessary and even still debug. The downside is that you'll lose out on some time if there are bugs or changes in your logic because you're editing and rebuilding those separate from Unity, but in a lot of cases this won't have much of an impact because those subsystems can be made solid and unit tested first. You can even reference the UnityEngine.dll and create Monobehaviours in your precompiled DLLs, but beware that will break your ability to unit test anything that requires you to load that DLL.

 

I'm not sure I follow. I probably worded this badly, I don't mean 'build time' as in generate out a full build (file menu->build), I mean like make a change to a .cs file, and have those changes reflected in the editor both in the inspector and in playmode. This is ctr + r if you disable auto refresh, or the process that kicks off when you tab back into unity after making a file change if you have auto refresh enabled.

 

Yeah I would recommend migrating subsystems to precompiled DLLs as you solidify them. They may still require changes but not many, and in that case they are good candidates to precompile.

 

So how exactly do you set this up?

Unity Solution
- first pass project
- editor project
- game project

Secondary Solution
- subsystem 1
[Builds to Assets folder]

Is it really that simple? Why didn't I do this eons ago? Any idea how this might affect editor scripts - is it possible to also put these in the Secondary Solution and output to dll that's picked up in unity?
EDIT: just looked up the answer, you apparently can do editor scripts as dlls just as easily. This might be great.

 

Exactly how I would set it up. The only reason you do two solutions is so visual studio doesn't try to build your unity project, but yeah you can even put MonoBehaviours in a separate project, although AOT doesn't seem to chuck a wobbly if you have a MB in one DL that inherits a MB from another (this may have been fixed).

One note: Build your secondary DLLs in Debug mode to make sure you can step into and debug them, but don't forget to recompile them to Release mode before publishing or doing real performance testing of your app.

 

Oh, my mistake.