Unity Build Fails with Error CS0246 Type or Namespace Not Found - Assembly Fix

Problem: Your Unity project builds in the Editor but fails when building for a platform (e.g. Windows, Android, WebGL) with error CS0246: The type or namespace name 'X' could not be found (are you missing a using directive or an assembly reference?). Sometimes the same error appears in the Editor Console. The type or namespace might be from a package, a plugin, or your own code in another assembly.

Root cause: CS0246 usually means the compiler cannot see the assembly that defines that type. Common causes: (1) the script that uses the type is in an Assembly Definition (asmdef) that does not reference the assembly where the type lives; (2) the type is in a package or plugin that is not included for the build target; (3) conditional compilation or platform defines hide the type on that platform; (4) the type was moved or renamed and references are broken. Fixing it is almost always about correcting assembly references or build inclusion.

This guide gives you step-by-step fixes so you can resolve CS0246 and get your build succeeding again.

Quick Fix Checklist

Before going into detail, check:

Assembly Definition (asmdef) – If your script is in an asmdef, that asmdef must reference the assembly that contains the type (e.g. another asmdef, or Unity’s assembly like UnityEngine).
Package / plugin – The type might come from a package (Package Manager) or a plugin. Ensure the package is installed and that no platform or define excludes it from the build.
Using directive – Add the correct using Some.Namespace; at the top of the file if the type is in a namespace.
Build target – Some code is Editor-only or platform-specific; the type might not exist for the platform you are building for.

If you are not sure which assembly defines the type, use Solution 1 to find it, then apply the assembly or asmdef fix.

Solution 1: Add the Missing Assembly Reference (asmdef)

Symptom: Error says a type or namespace could not be found, and the script that uses it is inside an Assembly Definition (.asmdef) file.

Step 1: Identify where the missing type lives. In the Project window, search for the type name (e.g. the class name). Open one of the result files and check the top: if it’s in an asmdef folder, note that asmdef’s Assembly Name (Inspector when you select the asmdef).

Step 2: Select the asmdef that contains the script with the error (the one that “cannot find” the type).

Step 3: In the Inspector, find Assembly Definition References. Click the + button and add the assembly that defines the missing type (the asmdef you found in Step 1, or a built-in assembly like UnityEngine, UnityEditor, Unity.InputSystem, etc.). If the type is in a package, add the package’s assembly (e.g. Unity.InputSystem for the new Input System).

Step 4: Save the asmdef and let Unity recompile. The CS0246 error should disappear if the only issue was the missing reference.

Verification: Build again for your target platform. If CS0246 persists, the type might be in an assembly that isn’t available for that platform (see Solution 3).

Pro tip: Asmdefs create an assembly boundary. Any script in Assembly A that uses a type from Assembly B must list Assembly B in its “Assembly Definition References”. This is the most common fix for CS0246 in projects using asmdefs.

Solution 2: Add the Correct Using Directive

Symptom: The type exists in your project or a package but your script doesn’t have the right namespace imported.

Step 1: Find the file that defines the type (search by type name in the Project window). Open it and check the namespace (e.g. namespace MyGame.UI { ... }).

Step 2: In the script that reports CS0246, add at the top: using The.Namespace.Name; (replace with the actual namespace). Save and let Unity recompile.

Step 3: If the error is about a nested type, use the full type name once to see if it resolves, e.g. MyNamespace.Outer.Inner. If it does, you can add a using for MyNamespace or use the full name where you reference it.

Verification: The Console should no longer show CS0246 for that type. If it does, the problem is likely assembly scope (Solution 1), not the using directive.

Common mistake: Adding a using for a type that lives in another assembly without adding that assembly to your asmdef (Solution 1). Both the reference and the using are required when using asmdefs.

Solution 3: Ensure the Type Is Available for Your Build Target

Symptom: The type is found in the Editor but CS0246 appears only when building for a specific platform (e.g. WebGL, Android), or the type is in an Editor-only assembly.

Step 1: Check if the type is in an Editor-only assembly. Many packages have a separate assembly like MyPackage.Editor. Scripts that run in builds (e.g. in Runtime) must not reference Editor-only assemblies. Move the usage behind #if UNITY_EDITOR or use a shared runtime assembly that is referenced in builds.

Step 2: For packages, open Package Manager and confirm the package is installed and compatible with your build target. Some packages or APIs are Editor-only or not supported on certain platforms; the documentation will say so.

Step 3: If the type is guarded by scripting define symbols (e.g. #if ENABLE_INPUT_SYSTEM), ensure the same defines are set in Player Settings > Script Compilation > Script Compilation Defines (or in the platform’s settings) for the build target. If the define is missing in the build, the type might not be compiled in and you’ll get CS0246.

Verification: Build for the problematic platform again. If the error is gone, the fix was making the defining code (and its assembly) available for that target.

Solution 4: Fix Broken References After Rename or Move

Symptom: You renamed or moved a script/class, or refactored a namespace, and CS0246 appeared in scripts that used to see the type.

Step 1: Use Find References (right-click the type/script in the Project window, or search in your IDE) to see every file that references the old name or namespace.

Step 2: Update those files: correct the namespace in using statements and any fully qualified type names. If the class was renamed, update all references to the new name.

Step 3: If you use asmdefs and you moved the defining script into a different asmdef, update the Assembly Definition References in any asmdef that references the old assembly (the definition may now be in a different assembly name).

Step 4: Let Unity reimport and recompile. Clear any stale errors with Console > Clear and rebuild.

Verification: Full rebuild (Build, or Rebuild All in Console). CS0246 should be gone for that type.

Solution 5: Reimport Packages or Restore Assembly Definitions

Symptom: CS0246 appears after updating Unity, adding/removing a package, or copying the project. Types from packages or other assemblies are “not found”.

Step 1: In the Package Manager, try Reimport or Update for the package that should provide the type. Sometimes the package cache or asmdef references get out of sync.

Step 2: Remove and re-add the assembly reference in your asmdef: in the asmdef that has the error, remove the reference to the assembly that should contain the type, apply, then add it again and save. This can refresh Unity’s view of the reference.

Step 3: Refresh the Asset Database: Assets > Refresh (or Ctrl+R). If that doesn’t help, close Unity, delete the project’s Library folder (or at least the ScriptAssemblies subfolder), then reopen the project so Unity recompiles from scratch. Only do this if you’re comfortable reimporting the project.

Verification: After reimport/recompile, build again. If the package or assembly is correctly installed and referenced, CS0246 for that type should be resolved.

Prevention Tips

When creating new asmdefs, add references to UnityEngine (and UnityEditor only for Editor code) and to any other assembly whose types you use.
After adding a package that you reference from code, ensure your asmdef references the package’s runtime assembly (check the package’s documentation or its asmdef in the package cache).
Avoid referencing Editor-only assemblies from runtime scripts; use interfaces or build-time stripping so runtime code doesn’t depend on Editor types.
Use consistent namespaces and avoid renaming/moving types without updating references and asmdefs.