Microtube Unity version support
Which Unity versions HEXR runs on, and how to diagnose a project that stops compiling after an editor upgrade.
Which Unity versions HEXR supports
The package declares "unity": "2022.3" and runs from Unity 2022.3 LTS through Unity 6.x off a single codebase. There is no separate branch or package per editor version.
| Unity | Status |
|---|---|
| 2022.3 LTS | Supported — the declared floor |
| 2023.2 | Supported — package assemblies verified to compile with no errors and no deprecation warnings |
| Unity 6 (6000.x), through 6000.5 | Supported — verified the same way |
| Later releases | Not yet verified. See why upgrading breaks things for what to expect |
A Unity upgrade far more often breaks your XR backend than it breaks HEXR. The Meta XR SDK in particular is pinned to an editor range, and the wrong pairing stops the whole project compiling — including code that has nothing to do with it. Read Meta XR SDK pairing before assuming the fault is in HEXR.
Why upgrading Unity breaks packages
Unity retires API in two stages, and the gap between them is where projects get caught out.
First it becomes a warning
The method still works. The compiler emits CS0618 and the console shows a yellow warning. Almost everyone ignores it, because nothing is broken.
Some versions later it becomes an error
Unity flips the same attribute to error level. The compiler now emits CS0619 and the assembly no longer builds. Nothing about the code changed — only the editor did.
The example most likely to hit a Meta project: Object.GetInstanceID() was a warning for several releases, then became a hard error in Unity 6000.3 in favour of GetEntityId(). Any package still calling it stopped compiling on upgrade.
Yellow warnings after a Unity upgrade are not noise — they are the list of things that will become build errors on the next upgrade. Clearing them while they are still warnings is far cheaper than clearing them once they block your build.
Step 1: work out whose code is failing
This is the most useful triage step and it takes one glance at the file path in the error. Do it before reading the error text.
| Path in the error | Whose code | What you can do |
|---|---|---|
Library/PackageCache/… | A third-party package — Meta XR SDK, a Unity package | You cannot fix this by editing the file. It is a regenerated cache and your edit is erased on the next reimport. Change the package version instead |
Packages/… | An embedded package, HEXR included when it is vendored into a project | Editable and persistent, but you are forking it — the change is lost on the next package update |
Assets/… | Yours | Fix it directly |
If every error sits under Library/PackageCache, no amount of work on your own scripts will help. The fix is a version change.
Step 2: decode the compiler error
Unity surfaces raw C# compiler codes. The code tells you which kind of version mismatch you are looking at.
| Code | Means | Usual cause after an upgrade |
|---|---|---|
CS0619 | API is obsolete and flagged as an error | Your editor is newer than the package expects. The package has to be updated — this one cannot be suppressed |
CS0618 | API is obsolete, warning only | Still builds. This is your advance warning list for the next upgrade |
CS1061 / CS0117 | The type has no such member | Your editor is older than the code expects — the member does not exist yet. Downgrade the package or upgrade the editor |
CS1503 | Argument type does not match | The overload being called was added in a later version |
CS0246 | Type or namespace not found | A package is missing entirely, or its assembly definition is not referenced |
#pragma warning disable and the -nowarn compiler switch only affect warnings. CS0619 is an error, so neither works on it. Advice online telling you to suppress it is advice about CS0618. There is no way around a CS0619 except changing the code or changing the version.
Step 3: fix in the right order
Unity compiles assemblies in dependency order and stops at the first one that fails. Everything depending on it is never compiled, so its errors never appear.
This matters more than it sounds. A console showing three errors is not a three-error problem — it is the first failing assembly, and there may be far more waiting behind it. Fix what is reported, recompile, and see what surfaces. Do not estimate the size of the job from the first console output.
Work from the bottom of the dependency chain up: the XR backend first, then HEXR, then your own scripts.
Meta XR SDK pairing
The Meta XR SDK is pinned to an editor range and Meta ships a different SDK line for each one. Pairing it wrongly is the most common way a Meta project stops compiling after an upgrade, and the errors all land in Library/PackageCache/com.meta.xr.… — nowhere near your own code.
Check the pairing first: open Packages/manifest.json and compare com.meta.xr.sdk.all against the "unity" field in the SDK’s own package.json. If the SDK says 2022.3 and you are running Unity 6, that is your answer.
The Meta packages are transitive dependencies of com.meta.xr.sdk.all. Bump that single entry in manifest.json and Unity re-resolves the rest. Then close the editor, delete Library/PackageCache/com.meta.xr.*, and reopen so the cache is rebuilt.
How HEXR stays version-neutral
Every engine API that differs across the supported range is routed through one file, Runtime/HexR/HexRCompat.cs. The version guards live there and nowhere else, so when Unity retires something the change is one line in one place rather than a hunt across the package.
It is a pattern worth copying in your own code. What it currently covers:
| Unity API | The problem | HEXR calls |
|---|---|---|
FindObjectOfType, FindObjectsOfType | Deprecated from 2023.1 | HexRCompat.FindAny / FindAll |
FindObjectsSortMode | Fine until 6000.4, deprecated in 6000.5 | HexRCompat.FindAll |
Rigidbody.velocity | Renamed to linearVelocity in Unity 6; the new name does not exist before it | HexRCompat.GetLinearVelocity / SetLinearVelocity |
Before 6000.5 scene searches returned objects sorted by InstanceID. From 6000.5 Unity removed that guarantee, because InstanceID is being replaced by EntityId. If two objects in your scene share a name, which one a by-name lookup finds is deterministic on older editors and arbitrary on 6000.5+. Give objects unique names rather than relying on the old ordering.
Checking an API before you upgrade
You do not have to install an editor to find out whether it will break you. Every Unity install ships its own reference assemblies and a C# compiler, so you can compile a few lines against any version you have on disk and read the real diagnostics — the same ones Unity would print.
Put the calls you are unsure about in a small file, then compile it against that editor’s assemblies:
# Point this at the editor you want to test against
UNITY="C:/Program Files/Unity/Hub/Editor/6000.5.7f1/Editor/Data"
DOTNET="$UNITY/DotNetSdk/dotnet.exe"
CSC="$UNITY/DotNetSdk/sdk/8.0.318/Roslyn/bincore/csc.dll"
REFS="$UNITY/Managed/UnityEngine"
"$DOTNET" "$CSC" -nostdlib+ -target:library -out:probe.dll Probe.cs -r:"$UNITY/NetStandard/ref/2.1.0/netstandard.dll" -r:"$REFS/UnityEngine.CoreModule.dll" -r:"$REFS/UnityEngine.PhysicsModule.dll"The output says exactly which stage of the retirement cycle each call is in — clean, CS0618 or CS0619 — before you commit to the upgrade. It is also how the support table on this page was produced.
Reporting a version problem to us
If HEXR itself will not compile on your editor, the fastest report includes:
| What | Where to find it |
|---|---|
| Exact editor version | ProjectSettings/ProjectVersion.txt — the full string, e.g. 6000.5.7f1 |
| HEXR package version | The "version" field in the package’s package.json |
| Your XR backend and its version | Packages/manifest.json |
| The first errors, with file paths | The Unity console. Paths matter as much as messages — they say whose code failed |
Send it through contact. A screenshot of the console with the file paths cropped off is the one thing we cannot act on.