Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
In which we generate some actual project files for Visual Studio consumption, put all the pieces together and I finally finish writing about this crazy ride of a build process. Onwards! To greener pastures!
And so we come to our final piece of the puzzle. The "putting it all together and hoping it was worth our trouble" piece. In the form of the humble .csproj file and its accompanying common properties targets file. For those of us joining just now, please check: part 1, part 2, and part 3. Especially part 3 as we mostly build on top of it. I also suggest looking through the Visual Studio generated .csproj and identify commonalities, that's what I've done and the reason I drew out the properties that I did.
Alright, goggles on, let's go swimming with the XML dolphins.
First file I'm showing contains the common properties for all our project files. These properties are MSBuild specific and define things like debug symbols, platform type, output type etc. Again, for a complete breakdown please follow the relative MSDN pages. I will point out however that I'm only building libraries for release and without debug symbols (not even .pdb files). I do have "dev" builds (what Visual Studio usually calls "Debug" builds) but it's a bit more involved and we don't need them at the moment since we're not attaching a debugger to Unity.
With all four custom targets defined for our building process we're left with the task of fitting all the pieces together into a single project file. And without further ado, I present you with;
Okay, few notes about this one. First, the "AssemblyName" property is also used by the properties targets to set the default namespace of newly created files in Visual Studio. And secondly, this is the runtime version of the file. You can tell by the specialized property called "UnityTarget". This is not an MSBuild property but our own and is used by the target selector to reference the correct libraries (ie. not the editor) as well as output the library to /Assets/Code/Runtime/ folder. When we want a project to be used within the editor context of Unity we simply need to set the "UnityTarget" to 'Editor'. This will also output the library into the /Assets/Code/Editor/ folder as required by Unity itself.
You can download and check an example here.
Wow, done. It's been a bit of a ride but heck we made it through mostly unscathed and with our sanity intact. One last tip I would like to offer when adding more references to the project (either manually or via Visual Studio) is to remember to set the private field on each reference to false so the libraries aren't copied; I think Visual Studio calls it something else in the properties control.
'till next time, adieu.
You May Also Like
