Bits of .NET

🛠️ The Hot Reload That Quietly Stopped Reloading

Hot Reload applies a specific category of code edits to a running application without a full rebuild and restart – mostly method body changes – and it silently falls back to doing nothing the moment an edit falls outside that supported set, such as adding a new field or changing a method’s signature, without always surfacing a message that clearly explains which edit actually broke it. Once Hot Reload has quietly stopped applying changes for a debugging session, every edit made after that point can look completely normal – the file saves with no error – while the running process keeps executing the old code underneath it, right up until an actual restart.

🔎 The Problem

Session sequence that silently stops working:
  1. Start debugging, make a few method-body edits - Hot Reload
     applies each one correctly, visible behavior updates live
  2. Add a new field to a class, or change a method's signature, to
     support the next change - this edit falls outside what Hot
     Reload supports
  3. Make another, perfectly ordinary method-body edit afterward -
     it saves normally, with no visible error anywhere, but the
     running process is still executing the OLD code the entire
     session from that point forward
  4. Behavior stops matching what was just edited, with nothing in
     the editor itself indicating Hot Reload gave up partway through
     the session

Checking the Hot Reload toolbar button and its own diagnostics output
specifically, right after any structural edit, is what actually shows
which edit fell outside the supported set - it is easy to miss in the
moment because the edit itself always still saves without an error.

✅ Fix: Watch for the Unsupported-Edit Notice, and Restart When Unsure

• Watch the Hot Reload toolbar button and its own diagnostics output specifically after making a structural change, such as a new field, a changed signature, or a new class member – Visual Studio does log which specific edit fell outside the supported set there, even though it is easy to miss in the moment because the edit itself saves with no visible error.
• Treat any edit that adds or removes a member, changes a method’s signature, or changes a type’s hierarchy as very likely requiring a full restart to actually take effect – the supported edit set is narrower than any code change in general, and a plain method-body edit is the safe, reliable case to expect it to handle.
• When behavior does not match what was just edited and it is unclear whether Hot Reload actually applied the change, stop the debugger and restart rather than continuing to debug against what might be stale, pre-edit behavior – a few seconds restarting is far cheaper than an extended debugging session built on the wrong assumption about which code is actually running.

⚠️ Why This Is Easy to Miss

• The edit itself always saves normally, and the IDE gives no persistent, hard-to-miss error for an unsupported edit – any notice is typically a brief status message that is simple to not notice if you are not watching for it at that exact moment.
• Once Hot Reload silently stops applying changes partway through a session, every subsequent edit looks exactly the same as a working one from the editor’s point of view – there is no visual difference between an edit that just got applied successfully and one that silently did not, until the running behavior itself fails to match what was expected.