Unity: pros and cons of coding into DLLs

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.
• Keeping the code completely separate from your Unity project is always a cool thing, in my opinion.

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.
• You cannot debug your classes by attaching your IDE to Unity’s editor.

Additional Cons thanks to Mr Dmitriy Focus:

• Writing code in VS and deploying it as DLL prevents out-of-the-box Unity-specific conditional compilation usage. Like #if UNITY_EDITOR, UNITY_FLASH, etc., for extra flexibility of your plugin for example.
• 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.