UnityAssemblies

Background

Unity3D (or UnityAssemblies) is an open-source NuGet package that I started in 2019. Oh, and Unity® and the Unity logo are trademarks of Unity Technologies.

Having worked with the .NET stack since ~2014, I was always frustrated when Unity's builtin Mono compiler didn't allow me to use the latest .NET Standard APIs or C# language features, especially after C# 6.0 dropped with great features like nameof and null-conditional operators. To get around these limitations, I started writing my C# scripts in Visual Studio instead, then exporting the compiled DLLs to my Unity projects with an MSBuild post-build event (this was actually the subject of my GDEX 2019 talk.)

I came to realize that this setup actually had a number of benefits:

  • The aforementioned access to the latest C# language features (at least those that didn't also require the CoreCLR)
  • A useful separation between programming "sources" and "assets". That is, .cs source files could be stored in one folder of a repository outside the Unity project while the compiled DLLs were stored in the Unity project. This is similar to the separation for other assets (e.g., between PhotoShop .psd files and final images, or .blend files and final 3D meshes).
  • Storing source files outside the Unity project also avoids "double compilation" of library code by both Visual Studio and Unity (Mono).
  • Improved reusability: shared code (like my UnityUtil library) can be moved to an entirely separate repository and imported as a .unitypackage or via a package manager like NuGet or UPM.

The last benefit is what led me to create the Unity3D NuGet package. Unity programmers like me could create Visual Studio solutions for their scripts, add this package, and then they would have access to all of Unity's assemblies via MSBuild targets/properties. The Why Another NuGet Package for Unity? section of the project's README expands on other packages that I considered and why I found them insufficient. And I think others agreed! As of this writing in 2024, my package has ~100 stars on GitHub and is easily my best-managed open source project, while those other packages are no longer maintained.

Technical Details

I am proud of several technical details in this library:

  • The thorough documentation in the README, complete with code samples and clear formatting.
  • The inclusion of typical open-source "Community Standards", including a README.md, Code of conduct, CONTRIBUTING.md, and LICENSE.md.
  • Adherence to the Keep a Changelog and Semantic Versioning standards.
  • The use of test Visual Studio solutions and Unity projects to verify that everything builds correctly before publishing new versions (documented in the CONTRIBUTING.md file).
  • The complexity of MSBuild property functions used in the main .props file.