I organize my scriptable object asset menu listings by using an editor only variable that holds a menu path (so I don’t have to manually put in this path, and can also easily change the path naming per project if needs be). Looks like this:
[CreateAssetMenu(fileName = "ResourceListObject", menuName = EditorGlobals.scriptableObjectMenu + "ResourceListObject ", order = 1)]
That EditorGlobals is an editor only class though, and trying to build my project, it throws an error:
“The name ‘EditorGlobals’ does not exist in the current context”
This is just the tip of the iceberg though: I’m getting a massive list of errors referencing editor only stuff, such as
“The type or namespace name ‘UnityEditorInternal’ could not be found (are you missing a using directive or an assembly reference?)” (that one is one of Unity)
and a whole bunch of custom property drawers I have in an assembly definition set to editor only (and which is placed in an “Editor” folder).
Anyone has any ideas how to go about any of this? I should mention I’m using assembly definitions here, which is probably the cause of his mess, but maybe someone has an elegant way if builds ignoring editor only stuff?
Please post an example SO script code and a screenshot of the AsmDef inspector.
Note that if you reference that editor-only AsmDef in another AsmDef that‘s used at runtime you‘ll get exactly this issue, you‘d still have to #if UNITY_EDITOR enclose every reference to an object that‘s from the UnityEditor namespace/assembly in that case. I suspect referencing the editor asmdef is most likely the issue here.
I’ve posted the relevant line of code above. The SO code itself is not relevant to this (if I would replace that EditorGlobals.scriptableObjectMenu for a string, the issue goes away).
I’ve also tried wrapping things in #if UNITY_EDITOR like you mention, but I get the exact same issue.
To clarify:
I have a bunch of scripts in a folder containing an assembly definition. In that folder is an Editor subfolder. This folder holds some custom drawers and a static EditorGlobals class containing some editor only variables.
It seems the Editor folder gets excluded from the build (as it should be) but references to stuff in that editor folder cause the build to fail. Obvious you’d think, were it not for those references being attributes (like property drawers, or in this case, “CreateAssetMenu”).
I was in the process of creating a simple project for a bug report, thinking it was an assembly thing, but it happens with non-assembly projects as well; editor only attributes (like custom property drawers) get pulled in and break the build by referencing editor folder content. Moving the classes out of an editor and wrapping it in #if UNITY_EDITOR has the exact same result.
(Also, using editor folder assembly definitions turns out to be a no go anyway, since more complex editors need to be able to reference the classes for which they provide an interface. If they fall under their own asmdef, this referencing becomes cyclic.)
Sure, because CreateAssetMenu is not an editor only attribute! Most, if not all attributes are in the UnityEngine namespace so that you do not have to #if all of them away like for example [SerializeField]. But the EditorGlobals reference is editor-only and thus you are including an editor-only reference.
And be aware that if you have this layout:
-
/SomeFolder
-
several scripts …
-
SomeFolder.amsdef
-
/Editor
-
editor only scripts …
All the scripts under SomeFolder and its subfolders belong to the SomeFolder.asmdef. There is no „Editor“ special folder behaviour anymore when a parent folder contains an asmdef! You‘d have to add another .asmdef to the Editor folder and declare it as Editor-only.
If you run into cyclic references think about the architecture some more. They can all be avoided. Editor asemblies can reference runtime assemblies but whenever you find you‘ll need to reference something from the editor assemblies in runtime scripts you should declare whatever you need there in the runtime assemblies.
Ok so it seems my the main problem I’m having was working under the assumption that Attributes are editor only.
They are indeed not.
I’ll be wrapping those asset menu things in an #if UNITY_EDITOR.
Additionally, the 100s of issues I have with propertydrawers are of the same nature: I assumed both custom attribute and propertydrawer were to be put in the editor folder. But they are not: only the drawer goes there; the attribute itself needs to be in the runtime environment.
So I’ll be spending some time separating a few dozen drawers that way. Hopefully that resolves all issues.
As for hierarchy: as you are describing it is how I have it. It does appear that Editor folders get excluded as they should, which means I won’t have to create editor folder asmdefs. If I do, hopefully having moved attributes from editor to runtime also prevents the cyclic issue (since I was referencing the Editor folder from runtime to have it find those attributes)
Actually, might have been wrong about those editor folders not being included; it just seemed that way because I had wrapped a whole bunch of code in there in #if UNITY_EDITOR directives… splitting attributes from their drawers seem to be resolving the issues so far.
thanks by the way for your assistance @CodeSmile
If you’re using your own attributes yourself for editor purposes, worth noting you can make attributes compile conditionally using the System.Diagnostics.Conditional attribute. Putting [Conditional("UNITY_EDITOR")] on your own editor only attributes should prevent them from compiling into builds, without the need to surround them in pre-processor directives.
1 Like
Thanks, I’ll be trying that!