The ASMDEF era cometh.
I decided on the above image for this weeks blog post, as although Unity advocates that using Assembly Definition Files will tidy your desk and clean up your coding practices, it is still a foreign concept to many. Unity have opted for this architecture and as such, none of us will have a choice of using it or not. You see the fact is, if one asset uses ASMDEFs, we all have to use it.
Now I have not as yet delved into the depths of ASM definitions, but I have spent many hours this week finding out why I need them and how to use them. There are many tutorials on using ASDDEFs in you code, and quite some documentation. However, even for a seasoned developer like me, much of it may as well be written in Japanese as they all seem to tell you something different.
While Unity states that this allows us to organize our code by creating separate assemblies and specifying dependencies between them, the only advantage seems to be that you will have faster compile times, as only the changes in code will be rebuilt. Sadly, I have not recorded any improvement in my build time, and it is not really a problem on my beast of a workstation.
The kicker is when Unity confirm that if you use Unity Package Manager in the future and many already do, code inside packages is required to have an Assembly Definition. Hence we will not have a choice. Creating these ASMDEFs is not difficult, but can be time consuming and at times confusing. I will look to write a tutorial in the near future explaining all the do's and don'ts of Assembly Definition Files, how to create them, and how to use them. But for now, as not to scare you all away, here is just a taste of what you are in for.
The main point you need to be aware of if you are writing code, is if you need to reference a method or variable in another asset that uses ASMDEFs, even if the method is defined as public, you will need to build an ASMDEF for your code and include the other asset as a dependency. But wait, there is more. If you also wish to access another asset that does NOT use Assembly Definitions, you will need to build ASMDEFs for that product, someone else's, and place it in their root folder. Strange but true.
And example: I am building a VR product and the front end uses WebXR for online access. WebXR uses Unity's Package Manager and hence has an ASMDEF. For my code to access any of the methods in WebXR, I needed to build an ASMDEF for my code, place it in my root folder, and reference the WebXR ASMDEF which resides in it's own root folder.
However, my code also uses Final IK from RootMotion, and I need to be able to set parameters at runtime for the Player character. But to do this, I need to create an ASMDEF for Final IK and place it in the Final IK root folder, or I will receive the infamous "are you missing a using directive or an assembly reference?" error, and it will not build.
But wait, there is even more. You must also create another ASMDEF for the Final IK (or whichever asset you need to reference) and place it in the Editor folder of that product, if it has one, as we all know that Editor folders are treated differently. The Magical nature of Editor folders does not work when using ASMDEFs, because they are still counted as a part of your higher level assembly, and therfore you will need to have a separate ASMDEF with Editor platform selected in the Inspector.
This is all just so my code can read one WebXR variable and update one Final IK setting, but I have no choice in this. As I wrote earlier, Unity is moving towards this architecture, and those of you who use Game Creator, GC 2 will also use ASMDEFs. I am yet to see how this will clean up my code, but I guess time will tell. One thing that I have already found, is that I need to restructure quite some design, and think a bit differently to make all this work efficiently. Maybe that's what Unity want.
So my readers, those of you who are Patrons and support the cause, I will be endeavouring to post some more code next week, as this week has been taken up with rebuilding my iMac hardware and creating the now infamous ASMDEF file.
Footnote: I read this post after I had published it and it reads a bit negative. This was not my attention but probably was a result of the frustration I had from all the conflicting information on this topic. The good news is that me having now dealt with this, as my Patrons you will not have to.