I have an assembly (say Example.dll ) with some mono behaviours (for instance ExampleBehaviour and a corresponding editor assembly (say Example.Editor.dll ) that should contain any unity-editor-related classes, including custom inspectors such as ExampleBehaviourInspector. The latter is decorated with [CustomEditor(typeof(ExampleBehaviour))]
Upon loading Unity, I am getting the error: “Can’t load custom inspector ExampleBehaviourInspector because the inspected type is null.” .
Do you have any clues how I could fix this? My wild guess is that comes from ExampleBehaviour residing into a separate assembly than its inspector, and somehow the assemblies are not properly loaded (in the correct order). But that should not be an issue, since from project’s scripts the editor-related code is compiled into a separate assembly than the game code.
UPDATE - Clarifications:
Both the Example.dll and the Example.Editor.dll are placed inside the Assets folder of the Unity project.
The DLLs have explicit versions, and the version of the Example.dll is the one the Example.Editor.dll requires (I update the revision number of those DLLs with each build, so I can guarantee they can co-exist correctly). My experience with unity is that it would crash if Example.Editor.dll depends on Example.dll (which is the case), but Example.dll is not found in the Assets directory – meaning Unity would demand all the dependent assemblies to be present. Thus, I would expect the types of those dependent assemblies to also be accessible.
The Example.Editor.dll’s import settings are configured to point only the Editor platform (the other ones are unchecked in the import settings window)
I have another pair of such DLLs tailored in the same fashion, that is working for a ScriptableObject, not a MonoBehaviour derivate, and another one that successfully creates a custom editor for a MonoBehaviour instance
The last point suggests that the occurrence of the problem is rather random, as I have a couple of successful use cases. The behaviour I observe, however, is consistent for the same project across multiple machines on which I have Unity installed (one laptop that uses Windows 8.1 Personal, a PC with Windows 7. and a Mac Mini running on Yosemite).
The reason seemed quite simple, and is strongly related to me using DLLs. As you know, I use separate dlls for the main Unity object/behaviour, and a different one for the editor-related stuff, in order to be able to compile the project. When the editor DLL is created (such as our Example.Editor.dll), Unity seems to store somewhere the exact version of its respective Example.dll - the one which stores the mono behavior. Each time I build a new version of Example.dll I will receive the error unless I build the Example.Editor.dll as well, and I must make sure it references the latest version of Example.dll during the build. I have consistently observed the disapearance of this issue for more than a month now while strictly sticking to the above practice - always build the editor DLL when the primary one changes.
I hope others having the same issue find this answer helpful. If there is indeed such a strong reference between compiled behaviors and their editors, it will be good to have this documented, as the issue seems quite hard to debug.
Below is my old assumption:
The issue was, however, a runtime error (NullPointerException in the case) from within the code of the inspector, that was caused by some of the classes I was using lacking a [SerializeField] attribute. There was no other error in the console besides the “Can’t load custom inspector … because the inspected type is null.”, which greatly impeded locating the root cause. Perhaps there is an issue with Unity not being able to properly catch and display the actual error in such circumstances.
Came across this when transitioning my company framework to a Unity local package in Unity 2018. Had the same error in the title pop up for custom inspector drawables now that the package structure requires they be separated into an Editor folder and Runtime folder with their own assembly definition files. I found that I had to add an AssemblyInfo.cs file to the Runtime folder with the following info:
using System.Runtime.CompilerServices;
[assembly: InternalsVisibleTo("com.company.package.editor")]