"Structural Razor edit hotload exception silently deregisters project tools"

Mid-edit, your project's custom editor tools all stop working — every tool call returns "Unknown tool". Yet the compiler reports success (Success=true, NeedsBuild=false). No amount of file editing, recompiling, or console commands brings the tools back.

A structural .razor change — one that adds markup or fields, shifting the generated class's b__NN lambda ordinals — can trigger a hotload exception like:

[hotload] Error: Unable to resolve method definition ... MyPanel.<SomeRow>b__74_0
Hotload exception

The game assembly's failed hotload leaves the dependent .editor assembly unloaded. Every project tool that was registered through that assembly disappears (the tool count drops by exactly the project's contribution). But the compile succeeded — the whitelist verdict (Success=true, zero SB1000 errors) is still trustworthy for API validation purposes. The failure is in the runtime assembly swap, not the build.

This is different from a success=False compiler wedge. Here the code is valid; the live runtime just can't hot-swap the new lambda layout.

Restart the editor. There is no lighter recovery:

• touch-ing files, content edits, and compile/hotload console commands do not re-register the tools — NeedsBuild stays false and the assembly remains unloaded.
• The editor restart loads the already-compiled (valid) assemblies fresh, re-registering all tools.

After restart, verify tools are back by checking the tool count or calling any project tool.

A fresh editor launch loads compiled assemblies from scratch, bypassing the failed in-process hotload path. The hotload system's lambda-ordinal resolution is fragile across structural changes (the old in-memory method map can't find the new b__NN slots), but a cold load has no old map to conflict with — it just loads the new assembly directly.