Why does Content Update create broken bundles after I changed a MonoBehaviour?

Content Update keeps the original player's bundle layout. If a script's serialized layout changes (added/removed fields, renamed type), bundles relying on the original assembly format break. Mark script-touching groups as Cannot Change Post Release so they go in the player build, not the content update.

What does addressables_content_state.bin do?

Snapshot of asset+dependency hashes from the player build. Content Update diffs the current project against it to decide which bundles to rebuild. Without it, Content Update can't run.

Pack Together vs Pack Separately?

Pack Together: one bundle per group. Pack Separately: one bundle per asset. Pack Together produces fewer files but Content Update may rebuild more. Pack Separately means small per-asset diffs at the cost of many files.

Fix: Unity Addressables Content Update Broken After Script Edit

Quick answer: Mark groups containing assets that reference your scripts as Cannot Change Post Release. Those go in the next player build, not in Content Updates. Asset-only groups (textures, audio) stay Can Change Post Release and ship via Content Update.

Patch goes out via Content Update CDN. Players crash on load. The culprit: a MonoBehaviour got a new field, the bundle still references the old layout, deserialization breaks.

The Symptom

After running Build For Content Update following script changes, deployed builds throw deserialization errors or have null references where serialized fields should be set. Original player builds work fine.

What Causes This

Addressables Content Update relies on assembly-stable deserialization. Scripts compile into the player assembly; bundles serialize references to types in those assemblies by GUID + offset. Editing the script changes the offset; old bundles can’t deserialize.

The fix is to never put script-referencing assets in Content Update groups. Force them into the next full player build.

The Fix

Step 1: Set group update restriction. Open Addressables Groups window. For each group, Inspector → Schema → Update Restriction:

Cannot Change Post Release — for groups with prefabs/scenes that reference scripts. Goes in player build.
Can Change Post Release — for groups with art only (textures, audio, materials, ScriptableObjects of stable types). Goes in Content Update.

Step 2: Build For Content Update. Window → Asset Management → Addressables → Build → Update a Previous Build. Pick the addressables_content_state.bin from the previous player build. Unity rebuilds only the Can Change groups.

Step 3: Snapshot the state. The state file lives in Assets/AddressableAssetsData/<Profile>/addressables_content_state.bin by default. Commit it after each player release; Content Updates diff against it.

Workflow

// On player release
1. Build > New Build > Default Build Script
2. Commit addressables_content_state.bin
3. Ship player build + initial bundles

// On content update
1. Edit only Can Change Post Release groups
2. Build > Update a Previous Build
3. Upload only the new bundles + updated catalog

Verifying

Run the player build with the Content Update bundles deployed. Profiler → Addressables Profiler shows which catalog version is in use. Loads should succeed without deserialization errors.

“Cannot Change Post Release for script-touching groups. Build For Content Update for art-only patches.”

Related Issues

For Addressables handle leak, see handle leak. For remote cache stale, see cache stale.

Lock the script bundles. Update the safe ones.