As the project grows from medium to large scale, the introduction of Assembly Definition (asmdef/assembly definition), which dramatically reduces the compilation time of the entire C# code, becomes an almost mandatory workflow. However, many developers run into the trap that as soon as they place asmdef files in each folder, their own editor extension classes such as custom inspectors and EditorWindow, which were previously working perfectly, fail to build with numerous compilation errors such as "UnityEditor namespace not found" and "Editor class cannot be inherited". In this article, we will provide a step-by-step explanation of the internal assembly boundary mechanism that causes this build collapse, an example that is easy for beginners to understand, and the correct assembly design to completely resolve compilation errors.

1. Understanding with an analogy: ``Export attache case'' and ``Large tools used exclusively for factories''

In order to intuitively understand this ``Editor code compilation error due to the introduction of asmdef'', let's consider ``packing products to be exported overseas and special tools used exclusively for factories'' as an example.

In your factory (project), "product parts (runtime code)" to be shipped and "large cranes and special screwdrivers (Editor extension code)" used only when assembling and inspecting products in the factory are placed together on the same shelf (in the same folder).

One day, in order to improve logistics efficiency, we decided to prepare a dedicated attache case (Assembly Definition) for each department, neatly classify product assets (module), and ship them overseas (actual machine build). However, a large factory-specific tool (API for UnityEditor) was accidentally slipped into the product case.

When the attache case arrives at the customs (build process), the customs official concludes, ``Hey! This case is meant to be shipped to the general public (smartphones and game consoles), but it comes with a huge factory-specific crane that the general public cannot use (it doesn't exist on the actual machine)! It's smuggling (compilation error)! The shipment will be stopped immediately!'' This is the true nature of the bug that causes you to complain that "UnityEditor cannot be found" when building. Factory-specific tools must be strictly isolated in a "separate specialized case (asmdef for Editor)" to be kept in the factory (editor environment), and packed completely separately from the export case.

2. Root cause: runtime-editor assembly boundary wall

Technically speaking, Unity's build system completely strips out code for editor-only functionality in the UnityEditor namespace and UnityEditor.dll when creating production binaries (production assemblies). This is because the editor engine does not exist on the actual device.

Before asmdef, Unity implicitly compiled all scripts in a project into a single giant assembly called Assembly-CSharp.dll. At this time, the scripts under the Editor folder were automatically classified and compiled into a separate editor-specific assembly (Assembly-CSharp-Editor.dll), which prevented reference errors.

However, placing MyFeature.asmdef in a specific folder (e.g. MyFeature) breaks the automatic classification rules. All scripts under that folder (including those in the Editor folder) are treated as belonging to the MyFeature assembly (a runtime assembly that is also included in the actual device). As a result, UnityEditor code will be mixed into the actual device code and will be rejected by customs (compiler).

Another problem is that separating the assemblies creates a "reference scope wall" that prevents the runtime from recognizing classes (such as MonoBehaviour) in the MyFeature assembly from the newly created MyFeature.Editor assembly.

3. Solution: Correct separation settings for assembly definitions

To resolve this assembly boundary error, you need to create and configure two asmdef files, one for runtime and one for editor.

Step 1: Organize folder structure and create asmdef for Editor

In the function folder, clearly separate the folder for runtime code and the Editor folder for editor extensions. 

Assets/
└── MyFeature/
    ├── MyFeature.asmdef           (ランタイム用アセンブリ定義)
    ├── PlayerMovement.cs          (製品用コード)
    └── Editor/
        ├── MyFeature.Editor.asmdef  (エディタ専用アセンブリ定義) ★新規追加
        └── MovementEditor.cs      (エディタ拡張コード)

* Create a new MyFeature.Editor.asmdef directly under the Editor folder.

Step 2: Set platform restrictions for asmdef for Editor

  1. Open the MyFeature.Editor.asmdef asset you created in the Inspector.
  2. In the Platforms section, change "Any Platform" to "Include Platforms".
  3. Check only `Editor` in the list (uncheck all other platforms, such as Android and iOS).

*As a result, the script in this assembly will be compiled only on the Unity editor, and will be automatically 100% excluded from the compilation target when building the actual machine.

Step 3: Adding Assembly Definition References

The Editor assembly references classes in the runtime assembly (such as PlayerMovement.cs) to draw custom inspectors, so you need to paste a reference link.

  1. Open the inspector for MyFeature.Editor.asmdef.
  2. Expand the Assembly Definition References item and press the `+` button.
  3. Add the runtime assembly `MyFeature` to the input slot.
  4. Press the Apply button to apply the settings. 
[MyFeature.Editor アセンブリ設定]
▼ Platforms
  ☑ Editor (エディタ環境のみ有効化)

▼ Assembly Definition References
  [+] MyFeature (ランタイム用アセンブリを参照)

4. Best practices for assembly division design

These are check items to keep the assembly structure of the project healthy.

  • How to use it with conditional compilation (#if UNITY_EDITOR): For small functions with only a few script files, it may be simpler and faster to write #if UNITY_EDITOR to #endif to enclose the editor API in the code, rather than creating an Editor folder and separating asmdef. Please design the assembly division granularity according to the overall scale of the project.
  • Disabling Auto Referencing: By turning off the Auto Referenced option for newly created asmdef assets, you can prevent unnecessary assemblies (e.g. test code assemblies) from being implicitly auto-referenced throughout the project, further improving compilation speed.