Use of libraries in projects on Unity3D

I don’t know how it is customary for anyone to write everything in one project, or someone may know that it is possible to put third-party assemblies in the Assembly folder (how many plugins are connected), and someone can even build their own libraries in the Assembly folder, but I did not see any information on how anyone does it, and any recommendations on how to set up your project so that you can program under Unity as if you were writing a serious application.

The bottom line is that usually the application is divided into modules, and each module is put into its separate Assembly. In this case, the module or library is not important, it is important that if you want to split your application into separate assemblies, then this is basically just enough to do, although there are some pitfalls. One of the main problems is that my approach will not work in the free version of Unity (it does not support the download of Assemblies at runtime), but for such a case there is a solution on the links of the file system, which I will discuss at the end.

What for?

Why break your application into separate modules / libraries? Perhaps many do not need to explain how good the grouping of code into libraries is, but in Unity you can live without them. Why do I do this? It is convenient for me to use the same libraries in my various projects, even samopisnye. First of all, even samopisnye. I keep each library in my repository, and if in one of the projects I find and correct an error in the library, then by a simple commit, push and pool from other projects, my fixes fall into all projects.

Project organization

I usually use libraries as submodules in the git repository. When I start a new project, I simply add to the empty repository all the library submodules that I will use. Sort of
')

 git init git submodule add my_rep/systemex.git Libraries/SystemEx 

I always put all libraries in the Libraries folder - it is so convenient for me. You can do as you like. Each library contains a project file with default settings. There is nothing special to change there, except for some cases. Unless install version .net framework in 3.5. But no, one more nuance - all library references must be set with Copy Local - False . This will save almost all the problems and oddities after the build.

Next, I create in Unity project files for the studio (I use visual studio, but the approach works for monodevelop). Unity creates something like _.sln , _-csharp.sln and Assembly-CSharp.csproj , Assembly-CSharp-vs.csproj files. It always recreates these files and it is not necessary to touch them. What needs to be done is to copy the _.sln into the _-bundle.sln and continue to work with it.

After that, I create into an empty class library, which by tradition I call Code and add it to a solution. She already needs to add all the libraries to the references and set them to Copy Local - True , although it should be the default. The second thing to do with this library is to set the Output Path: ..\Assets\Assemblies\ - I usually create this library in the root of the project, therefore ..\Assets\ - this is exactly the same Assets folder that Unity works with. And that's it, we compile the Code library, it puts the files in Assets \ Assemblies \, Unity sees these files and adds references to Assembly-CSharp.csproj . Everything should work like a clock. The only drawbacks are to double Assembly-CSharp.csproj build, and navigating through the code from the Assembly-CSharp.csproj project will not work.

After all this, my solution looks like this:


In the Code project, I write game logic that can be fumbled between projects. But he doesn’t see any gameplay from the game, so he can communicate with them only through SendMessage

Nuances

* In your libraries, you can use UnityEngine.dll - you just need to add it to the references, but it must turn off Copy Local otherwise it will go to the Assemblies and Unity will become ill.
* All libraries need to turn off Copy Local and leave it only for Code , otherwise there is a chance that something extra will be attracted. especially if you will also expand the editor. At one time, I suffered for some time with this, until I found the reason and the solution.
* You can extend the editor in the same way, but you need to lay out Code.Editor in the Output Path: ..\Assets\Editor\Assemblies\
* Unity does not like and does not understand if the same assembly lies in several folders.
* The mechanism works only for paid versions. More precisely, it’s possible to work with it for free, but it’s impossible to publish such projects.

If you want for free

In this case, you can also use the git and repository structure, only in places you will have to manually make links to the file system of folders with the library code in the Assemblies folder of the Unity project. And it will not be necessary to shamanize with the project files, Unity will do everything herself. Something like

 mklink /J .\Assets\Plugins\MathEx .\Libraries\MathEx\Assets\Plugins\MathEx 

In this case .\Libraries\MathEx\Assets\Plugins\MathEx folder is where the .cs files are located.

Thank you, I hope someone my advice will be useful. Keep your code clean.

upd: As ZimM wrote in the comments, in the free version, too, everything works fine. So the magic with the links of the file system in general is not needed. Thank him for that.

upd2: If you want debugging, and normal line numbers in the logs, you need to install UnityVS, which is now free and - most importantly - switch in all Target Framework projects from .NET 3.5 to Unity 3.5 .net Subset Base Class Libraries, or any other Unity 3.5 .net