Unity 6000.5 Breaking Change: Migrating InstanceID to EntityId

Introduction

Every major Unity upgrade comes with a familiar ritual: you hit Upgrade, wait for the reimport, and then watch the Console fill up with red CS0619 errors. Upgrading a real production project to Unity 6000.5.7f1 was no exception — but this time, almost every error traced back to the same root cause: Unity quietly replaced int instanceID with a brand-new struct called EntityId across a huge chunk of its public API.

This isn't a one-off obsolete method here or there. It's an engine-wide type change that touches GameObject, Object, EditorUtility, EditorApplication, and any of your own code that stored or compared instance IDs. If you maintain a project with third-party assets or your own Editor tooling, this is the change that will cost you the most time — so this post focuses entirely on it.

All the fixes below are 1:1 replacements. Nothing here changes your game's behavior — it just moves your code onto the current, non-obsolete API surface.

The Problem: int instanceID Is Being Replaced by EntityId

Historically, every UnityEngine.Object exposed GetInstanceID(), returning a plain int that uniquely identified the object for that session. Unity 6000.5 introduces EntityId, a lightweight struct that replaces int as the canonical identifier type across the Editor and runtime APIs. The old int-based members still exist for now, but they're marked obsolete and — in this project's case — configured to raise a hard CS0619 error, not just a warning:

error CS0619: 'EditorApplication.hierarchyWindowItemOnGUI' is obsolete:
'Use hierarchyWindowItemByEntityIdOnGUI instead. (UnityUpgradable)'

Once one script uses the old API, the whole project fails to compile — including Play Mode. Here's the full set of renames I had to apply.

Fix 1: GetInstanceID() → GetEntityId()

The most common change. Any code that grabbed a numeric ID for a GameObject, Material, or other Object needs to switch to the new accessor:

// Before
int uniqueId = sourceObject.GetInstanceID();

// After
EntityId uniqueId = sourceObject.GetEntityId();

This also means every Dictionary<int, T> or Dictionary<int, List<T>> keyed by instance ID needs its key type updated:

// Before
private Dictionary<int, List<GameObject>> instantiatedObjects = new Dictionary<int, List<GameObject>>();
private Dictionary<int, int> poolCursors = new Dictionary<int, int>();

// After
private Dictionary<EntityId, List<GameObject>> instantiatedObjects = new Dictionary<EntityId, List<GameObject>>();
private Dictionary<EntityId, int> poolCursors = new Dictionary<EntityId, int>();

EntityId implements equality and hashing correctly, so it drops into a Dictionary key exactly like int did — no behavior change, just a type swap.

Fix 2: EditorUtility.InstanceIDToObject → EntityIdToObject

Editor tooling that resolves an object back from its ID needs the matching lookup method:

// Before
GameObject gameObject = EditorUtility.InstanceIDToObject(instanceID) as GameObject;

// After
GameObject gameObject = EditorUtility.EntityIdToObject(entityId) as GameObject;

Fix 3: Hierarchy Window Callbacks

If you draw custom icons or overlays in the Hierarchy window, the delegate type and the event itself were renamed:

// Before
private static readonly EditorApplication.HierarchyWindowItemCallback callback;

static MyTool()
{
    callback = new EditorApplication.HierarchyWindowItemCallback(DrawIcon);
    EditorApplication.hierarchyWindowItemOnGUI =
        (EditorApplication.HierarchyWindowItemCallback)Delegate.Combine(
            EditorApplication.hierarchyWindowItemOnGUI, callback);
}

private static void DrawIcon(int instanceID, Rect selectionRect) { /* ... */ }

// After
private static readonly EditorApplication.HierarchyWindowItemByEntityIdCallback callback;

static MyTool()
{
    callback = new EditorApplication.HierarchyWindowItemByEntityIdCallback(DrawIcon);
    EditorApplication.hierarchyWindowItemByEntityIdOnGUI =
        (EditorApplication.HierarchyWindowItemByEntityIdCallback)Delegate.Combine(
            EditorApplication.hierarchyWindowItemByEntityIdOnGUI, callback);
}

private static void DrawIcon(EntityId entityId, Rect selectionRect) { /* ... */ }

Same pattern for subscribing/unsubscribing with += / -= elsewhere in your Editor code — just swap hierarchyWindowItemOnGUI for hierarchyWindowItemByEntityIdOnGUI.

Fix 4: The Semantic Trap — EntityId Has No Negative Values

This is the gotcha that won't show up as a compile error, only as a silent behavior bug. A lot of older Unity code used a simple convention: negative instance IDs mean the object exists only in memory (created at runtime, not saved as an asset), while positive IDs mean a persistent asset. Code relied on this to decide things like "should I duplicate this material" or "is this a scene instance vs. a prefab asset":

// Before – relies on int sign
instanceID = GetInstanceID();
if (instanceID < 0)
{
    DuplicateMaskedMaterials();
}

EntityId doesn't carry that sign convention — all its values behave as unsigned identifiers, so < 0 comparisons stop being meaningful. The correct replacement is to ask the Editor directly whether the object is a persistent asset:

// After – explicit intent instead of relying on ID sign
instanceID = GetEntityId();
if (!EditorUtility.IsPersistent(this))
{
    DuplicateMaskedMaterials();
}

Also watch for the "not yet initialized" check. Code used to compare against 0:

// Before
if (instanceID == 0) { instanceID = GetInstanceID(); }

// After
if (!instanceID.IsValid()) { instanceID = GetEntityId(); }

Fix 5: Serialized int instanceID Fields

If a MonoBehaviour serializes an instance ID to detect duplication (a common trick for "has this object been cloned since I last checked" logic), the field type itself needs to change:

// Before
[SerializeField]
int instanceID = 0;

// After
[SerializeField]
EntityId instanceID;

EntityId is a serializable struct, so this is a drop-in field type change — Unity handles the serialization for you.

A Broader Pattern: Obsolete-as-Error Is the New Normal

Beyond EntityId, this upgrade also flagged other engine APIs that were previously "soft obsolete" (a CS0618 warning) and are now hard errors under Unity 6000.5's analyzer settings — for example, HierarchyProperty (replaced by HierarchyIterator, or by SceneManager.GetRootGameObjects() for the common "enumerate scene roots" case) and MaterialProperty.type (replaced by MaterialProperty.propertyType returning ShaderPropertyType). The lesson generalizes: treat every CS0619 as a hard blocker, not something to silence with a pragma, because Unity is visibly trending toward making obsolete APIs non-negotiable rather than just discouraged.

A Practical Checklist for the EntityId Migration

1. Search your project for GetInstanceID(), InstanceIDToObject, hierarchyWindowItemOnGUI, and Dictionary<int, — these are the highest-hit-rate patterns.
2. For every serialized int that stores an instance ID, switch the field type to EntityId.
3. Audit any < 0 / > 0 / == 0 comparison on an old instance ID — these encode assumptions that don't hold for EntityId and need IsValid() / EditorUtility.IsPersistent() instead.
4. Update Dictionary/HashSet key types from int to EntityId wherever they were keyed by instance ID.
5. Rebuild (not just Play Mode) once the Console is clean — some of these paths only execute during a build or in batch mode.

Conclusion

Unity 6000.5's EntityId migration is the kind of change that looks like a simple rename until you hit the sign-comparison gotcha — and that's the part worth remembering, not just the syntax. GetInstanceID() → GetEntityId(), InstanceIDToObject → EntityIdToObject, hierarchyWindowItemOnGUI → hierarchyWindowItemByEntityIdOnGUI, and id < 0 → !EditorUtility.IsPersistent(this) were enough to get a real production project compiling and behaving correctly again on Unity 6000.5.7f1.

If you're hitting a specific EntityId-related error that isn't covered here, drop a comment or reach out — happy to help track down the fix.