Gamedev

I think it was a couple years ago, when, annoyed by name conflicts with loose Unity scripts and looking for better code completion, I decided to only code inside assemblies. Less than a month ago, I went back to loose scripts. Unity 4 finally introduced namespaces (even if with a few bugs), and insisting to put all code in DLLs was becoming an incredible pain in the ass. I will still use assemblies for plugins, since they’re easier to redistribute, but not any more for Unity projects.

In case you are confused by the difference between loose scripts and assemblies, it’s pretty simple. Loose scripts are the regular classes you create inside Unity. Assemblies are classes you create as a separate project, and then build all together as a DLL. Actually, when you compile your Unity project, Unity creates assemblies from all your loose scripts, but that’s another story.

So, after a long experience with Unity and assemblies, here is my astounding list of Pros and Cons:

Pros

You get a much tidier work environment.

If you’re not into MonoDevelop, and use Visual Studio instead, you don’t have to wait for Unity to startup a customized configuration.

If you’re on Windows, symlinks are the best way to share code between many projects, and DLLs are perfect for that.

When redistributing your code, DLLs allow you to give users a package which contains all the necessary stuff, and you won’t have to tell them “delete file X and file Y after updating, because they’re now obsolete”. Very convenient.

Cons

Interfacing with loose scripts is a pain in the ass, and considering that most Unity Assets come as loose scripts, you’re paving your road to hell, since the only viable solution is to create interfaces for every loose script you use. There are ways that allow assemblies to fully communicate with loose scripts, but they carry the risk of suddenly breaking your Unity project (and your heart, and your mental health).

Even if you use interfaces, interfaces are not serializable. So you won’t be able to assign them directly to your public Inspector-viewable properties.

If you’re compiling for iOS, sharing delegates between multiple DLLs will throw errors.

Inheritance should be used carefully, considering how Unity’s logic works, but still, Components that inherit from Components inside a different assembly will not appear in the Project window, when browsing your DLL.

All components inside an assembly are perfectly usable by Unity, but they’re randomly ordered (if you browse them by expanding the DLL in the Project window). Which is pretty annoying when you have many, and have to read through all of them to pinpoint the one you need.

It also makes project harder to obfuscate nicely – you need to obfuscate your library separately, which may lead to lesser obfuscation strengh.

In case of deploying some kind of security sensitive stuff in DLLs, you make hackers life easier – they may hack your DLL once and just replace it in all projects using it.

I’m not sure about latest Unity versions, but I remember how I lost all components linkages at game objects after removing DLL with component and moving there newer version after deletion in Unity 4.0.

2. It also makes project harder to obfuscate nicely – you need to obfuscate your library separately, which may lead to lesser obfuscation strengh.

3. In case of deploying some kind of security sensitive stuff in DLLs, you make hackers life easier – they may hack your DLL once and just replace it in all projects using it.

4. I’m not sure about latest Unity versions, but I remember how I lost all components linkages at game objects after removing DLL with component and moving there newer version after deletion in Unity 4.0.

And I’d not consider using VS for coding your DLL as pros, since you may easily use it to work with regular loose scripts as well and even debug your Unity app using UnityVS plugin.

Daniele

Hey, Daniele, thanks for including my comments into the post!
Regarding to conditional compilation absence – it’s pretty significant DLL disadvantage =( This is a main reason why I decided to distribute Anti-Cheat Toolkit with sources instead of DLL – I may easily add different workarounds for bugs and API restrictions (Flash Exporter has a lot of them) using conditionals.

Daniele

March 13, 2014

Thanks to you for mentioning those points. And yes, conditional compilation is incredibly cool, but I’m so used to just create separate conditional assemblies, that I still don’t realize how easier it is now that I went back to lose scripts :D