Analyzing Unity Application

Introduction

Since version 2021.1 NDepend can analyze Unity applications.

In the picture below, we can see the panel NDepend > Project properties > Code to Analyze on a Unity application. Let's notice that:

• The .NET Profile is Unity. This profile is detected automatically when analyzing a Unity solution or some Unity assemblies..
• Directories that contain the Unity engine assemblies are automatically referenced.
• Unity engine referenced assemblies are automatically resolved.
• The runtime unity is shown for all application assemblies.
• Note that if some assemblies are compiled against .NET Standard 2.0 for example, netstandard20 is shown instead.
• Notice that the NDepend default rules take account of the Unity platform peculiarities and avoid showing false positives on Unity code. As explained below some rules are dedicated to Unity analysis.

Define the Unity Engine Referenced in the Registry

Per default the Unity Engine referenced by the NDepend project is the highest one found on the machine in C:\Program Files\Unity\Hub\Editor. As a consequence the Unity Engine referenced by an NDepend project deployed on several machines, can be different depending on the installation of Unity on each machine.

However if this registry key is defined on a machine, NDepend will use its value to locate the Unity Engine referenced:

HKEY_CURRENT_USER\SOFTWARE\Unity Technologies\Installer\Unity@Location x64

Browse how your application uses Unity APIs

It is quite interesting and informative to explore which Unity APIs are used by your application with the NDepend dependency graph.

All other NDepend use-cases work when analyzing Unity code.

Default Unity Rules

With NDepend v2021.1 new Unity default rules have been added:

• Classes tagged with InitializeOnLoad should have a static constructor
• Avoid using non-generic GetComponent
• Avoid empty Unity message
• Avoid using Time.fixedDeltaTime with Update
• Use CreateInstance to create a scriptable object
• The SerializeField attribute is redundant on public fields
• InitializeOnLoadMethod should tag only static and parameterless methods
• Prefer using SetPixels32() over SetPixels()
• Don't use System.Reflection in performance critical messages

---

Also since NDepend v2021.1 some Default rules have been updated to avoid false positives on Unity project:

• The rule Potentially Dead Methods doesn't warn on methods of classes that derive from a UnityEngine class.
• The rule Methods should be declared static if possible doesn't warn on methods of classes that derive from a UnityEngine class.
• The rule Fields should be marked as ReadOnly when possible doesn't match fields tagged with 'UnityEngine.SerializeField'.
• The rule Potentially Dead Fields doesn't match fields tagged with 'UnityEngine.SerializeField'.
• The rule Instance fields naming convention all fields named like properties when analyzing Unity code. Often for high-performance reasons fields are used instead of properties in Unity projects.
• The rule Fields should be declared as private is disabled when analyzing Unity code. Often for high-performance reasons public fields are used instead of properties in Unity projects.
• The rule Fields that could have a lower visibility doesn't match fields in classes that derive from a UnityEngine class.
• The rule Mark assemblies with assembly version is disabled when analyzing Unity code. You can still use the AssemblyVersionAttribute in Unity context as explained here.
• The rule Avoid types with too many fields has a threshold of 30 instead of 15 for Unity projects. This is because Unity classes tend to hold many numeric and graphics states (color, shaders...).