Quick answer: Reference the .inputactions asset via a serialized field, Resources folder, or Addressable. Unity only includes referenced assets in builds.
A puzzle game uses Input System with a Controls.inputactions file. Loads fine in editor; built game logs NullReferenceException at first input read. Asset wasn’t in the build.
Why It Works in Editor
Editor uses AssetDatabase; can load any asset by GUID instantly. Build only ships assets in the build set. Unreferenced files are excluded to keep build size lean.
Fix 1: Serialized Field
using UnityEngine.InputSystem;
public class InputController : MonoBehaviour
{
[SerializeField] private InputActionAsset actions;
void OnEnable() { actions.Enable(); }
}
Drag the .inputactions into the field in inspector. Builds include the referenced asset.
Fix 2: Generated C# Class
Right-click .inputactions in Project → Generate C# Class. Tick “Generate Class” in the asset’s Inspector. Then:
private Controls _controls;
void Awake() {
_controls = new Controls();
_controls.Enable();
}
Class instance creates the action map at runtime — no asset reference needed. Compiles into your assembly.
Fix 3: Resources Folder
// Assets/Resources/Controls.inputactions
var actions = Resources.Load<InputActionAsset>("Controls");
actions.Enable();
Anything in Resources/ always ships. Use sparingly — Resources are loaded into memory at startup.
Verify Inclusion
Build Report (Library/LastBuild.buildreport):
- Search for “Controls.inputactions”.
- If present: included. If absent: excluded.
Verifying
Build for target platform. Run; input responds. No null refs at startup. Profile memory; input asset weight is negligible.
“Unity builds only reachable assets. Reference your inputactions or generate the C# class to make it bulletproof.”
Generated C# classes are the cleanest: no inspector wiring, no Resources cost, fully refactor-safe. Use them.