koobas.hobune.stream
How to create a class library in Unity/UnityVS/MonoDevelop
I am trying to create a class library for my project. I create the new project in MonoDevelop, and add a reference to my Assembly-CSharp project. Write the code in in MonoDevelop, it compiles fine at both a project and solution level. Everything is referenced properly, there are no warnings or compile errors.
But once I get back into Unity and click Play, I get "The type or namespace name 'SimulationLibrary' could not be found. Are you missing a directive or an assembly reference?"
How do I reference other projects so that Unity can "find them" properly? I referenced UnityVS, because I also want this to work in UnityVS so I can use my Resharper abilities and test suites.
The way it currently works with UnityVS is as follows:
In Visual Studio, you create a normal class library project
You modify its properties to reference the Unity “target framework”
You either change the output directory of the class library to be in the Assets folder of your Unity project, or you add a postbuild step to copy the resulting dll and its pdb to the Assets folder
You add the class library as an existing project to the UnityVS generated solution
This way you have your class library in your project, UnityVS will transform the .pdb into something Unity understands, so you'll be able to put breakpoints in your class library on top of your game code.
Well, part of the issue has been, how do I configure a class library that I can also do TDD with an NUnit test class library. It never dawned on me to put the DLL output into the Assets folder ins$$anonymous$$d of bin. I'm very happy with your solution.
My guess would be that MonoDevelop doesn't include all the dependencies so that Unity can access them. Regardless of what actually happens, you should create a DLL of your class library and put that in a Plugins folder within your Unity Project.
This page explains the process: Using Mono DLLs in a Unity Project.
Thanks for you answer @Elenesski. I'm starting to regret splitting my code up into separate libraries!
I have a follow up question, what do you do with the dll.meta files and pdb.meta files that are generated by Unity. If I do a Git clean (or a fresh checkout) then open Unity, it promptly deletes all my .dll.meta and .pdb.meta files from my Assets folder as it can't find the class library files. Nor does it build as, of course, the class libraries haven't been built yet. When I do then build the class libraries in Visual Studio, Unity then regenerates all the .meta files with new GUIDs, which I believe will break things.
Is there an elegant way around this? Or do I have to something grim like putting the .meta files next to the dll in the class library and copying them across into the Assets folder too? Do you even need to commit the dll.meta files?
I'm wondering whether I should stop fighting the system. Do most Unity devs just use one big assembly (Assembly-CSharp) for all their code?
Why can't it find the class library files? I$$anonymous$$O you should put both the dll and its meta file into source control.
Commit dlls to source control? That just doesn't seem right. In an ideal world, one would only commit source files to source control. What happens e.g. if the dll exceeds the maximum size allowed by GitHub?
Seems totally right to me. They are source files (in the project they are used in, that is, obviously not in the project they're built in).
Do you keep the source of the library and the build of the library (.dll) along side in the asset folder? Why the library needs to be build if you include the .dll, what is the point of using libraries that way? You could seperate the code with namespaces, or if I am not mistaken latest versions of Unity allow to create several Assemblies (hadn't checked it though).
Well I guess my thinking is that the code in my class libraries is "pure" i.e. that they are completely independent from Unity and represent just my game logic. That way, if I decided to move to a different game engine, I'd be able to port these libraries across. Or I could bring them into another Unity project. I can also test them independently without any dependency on Unity e.g. build and run tests on a build server.
Fair enough, that s good, but complicates things. I would suggest to keep the source of the dlls in seperate project (cs project not Unity), now the location could be in the Unity project level (not in Asset Folder), so those files won't be handled by Unity (compiled nor metadata created), that way you can push the whole thing in git without breaking it, of course you keep the build dll in asset folder or plugins.
To make testing easier(in play mode) you could compile the dlls' source (and replace them) before the Hot reload event of Unity so changes made on the source of the dlls are present in Unity. The process can and should be automated, shouldn't be too hard. Cheers
Edit, if you don't won't to push the dll in git just add it to gitignore and the above mentioned process, given it happens before Unity compiles the scripts will create the dll.
