"Cross-assembly hot-reload throws MissingMethodException despite green compile"
▸ SYMPTOM
You add a new public method to your game assembly and call it from your editor-tools assembly. Both files are saved together. compile_status shows all-green, the headless dotnet build reports 0 errors/0 warnings, and the new tool even registers (you can see ToolCount bumped). But the first call throws MissingMethodException: Method not found at runtime.
▸ CAUSE
When both assemblies hot-reload in the same pass, the editor-tools assembly re-JITs against a stale copy of the game assembly that predates the new method. The MonoMod JIT hook resolves method references at reload time — if the game assembly hasn't finished reloading when the editor assembly resolves, the method doesn't exist yet.
Touching only the caller (editor) file alone does not clear the stale resolution. The compile is green because the compiler sees both source files — but the runtime resolver works against loaded assembly images, not source.
▸ FIX
Force the dependency (game assembly) to hot-reload independently before the caller:
- Make a trivial edit to the game-assembly file (add/remove a blank line)
- Let it recompile on its own
- Then save the editor-assembly file
The assembly that owns the new method must reload before (or independently of) the one that calls it. Order matters.
Standing rule: compile_status green is necessary but not sufficient across an assembly boundary. Always verify the actual runtime call after adding cross-assembly API surface in a hot-reload workflow.
▸ WHY IT WORKS
This produces a baffling false-green state — everything compiles, the tool registers, but the call dies at runtime. The fix is a 2-second workflow adjustment (reload the dependency first), but without knowing the cause you can waste a long time suspecting whitelist issues, naming bugs, or assembly corruption.
- Published