Visual Studio Hot Reload: Edit a Running .NET App Without Restarting

What Hot Reload gives you, and what it does not

Hot Reload in Visual Studio applies edits to managed code in a process that is already running. You change a method body, save the file, and the new behavior appears without stopping the debug session. Application state — in-memory caches, open connections, the values you set while stepping through code — survives the edit. That is the point: you avoid replaying the setup steps that got you to the interesting state.

Two boundaries matter. Hot Reload changes only the running process; it does not replace the normal build you will eventually need. And it applies a delta to code that is loaded, not a re-execution. Startup code that already ran will not run again just because you edited it.

Prerequisites

• Visual Studio 2022 or later with a supported .NET workload installed. Managed Hot Reload shipped alongside .NET 6; the set of supported edits has expanded in later releases.
• A project type the runtime supports for hot reload — ASP.NET Core, console, WPF, WinForms, and .NET MAUI are the common ones. Class libraries are edited through the app that references them.
• A Debug configuration. Optimized or Release builds are generally not eligible.
• The feature enabled under Tools > Options > Debugging > .NET/C++ Hot Reload. The exact page name and nesting have moved between releases, so confirm it in your installed version rather than assuming.
• A clean build before you start editing. If the project does not compile, there is no delta to apply.

Procedure: apply an edit to a running app

1. Open the project and press F5 to start with the debugger attached. Ctrl+F5 (start without debugging) also supports Hot Reload for several project types, but the debugger path gives you the rude-edit dialog and better diagnostics.
2. Confirm the app is running and note something stable about the process. In the example below, the app prints its process ID at startup.
3. Edit a method body in the running project.
4. Apply the change. Either press the Hot Reload button in the toolbar (it appears while the session is active) or save the file if Apply Hot Reload on File Save is enabled.
5. Exercise the changed path — refresh the endpoint, click the button, send the request — and observe the new behavior.

Concrete example: a minimal ASP.NET Core app. Put this in Program.cs and run it with F5.

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

Console.WriteLine($"Process ID: {Environment.ProcessId}");

app.MapGet("/greeting", () => "Hello from the first version");

app.Run();

Request /greeting and you get the first string. Now change only the literal:

app.MapGet("/greeting", () => "Hello from the edited version");

Save the file and request /greeting again. The new string should appear, and the process ID printed at startup should be unchanged. That PID is the check that separates "Hot Reload applied" from "the app silently restarted."

Changing a lambda body like this is a routine, widely supported edit. The same applies to most method bodies, and to adding members in many cases.

Expected checks

• The edit took effect. The new output appears on the next request or interaction, without a restart.
• The process did not restart. Compare the process ID, a startup log line, or any counter you print once at startup.
• No rude-edit prompt appeared. A prompt means the change was not applied.
• The build is still clean. Hot Reload applies deltas to a compiling project; a broken edit will not be applied.

When an edit is rejected: the rude-edit dialog

Some edits cannot be applied to a live process. These are called rude edits. They typically include changes to generic signatures or constraints, type hierarchies, base-class and interface lists, and some parameter renames. When Visual Studio detects one, it shows a dialog with roughly these choices:

• Stop and rebuild — the reliable path. The session restarts and the change is compiled normally.
• Revert — discards the edit and keeps the current session.
• Continue without applying — leaves the source file and the running code out of sync. Avoid this unless you intend to restart shortly; it is the main way people end up debugging code that is not the code on screen.

Dialog wording and the exact option set vary by Visual Studio release. Treat the rebuild option as the default answer.

General edit support, as a rough guide

Edit	Typical support	Notes
Method body change	Usually applied	The common case
Adding a method or field	Often applied	Varies by runtime and project type
Lambda or local function body	Usually applied	As in the example above
Changing a generic signature or constraint	Typically rejected	Rude edit; rebuild
Changing base class or interface list	Typically rejected	Rude edit; rebuild
XAML markup	Separate mechanism	XAML Hot Reload, not managed Hot Reload

This table is a planning aid, not a specification. The authoritative list is the runtime documentation for the .NET version your project targets, and it changes between releases.

Recovery and limitations

• Hot Reload is greyed out or unavailable. Check that the configuration is Debug, the project type is supported, and the option under Debugging is enabled. Some debugging settings inherited from Edit and Continue can also affect availability.
• The edit applied but nothing changed. The code you edited may have already executed — startup wiring, a constructor, a one-time initialization. Hot Reload does not re-run it. Restart the app.
• The app is in an inconsistent state. Stop debugging, rebuild, and start again. Hot Reload writes nothing beyond the file you saved, so there is no separate rollback step; undo the edit in the editor or use source control.
• Command-line equivalent. dotnet watch provides hot reload outside Visual Studio. It is a different tool with a different support matrix; do not assume an edit that works in one works in the other.

Because the supported edit set is version-sensitive, verify behavior on your own combination of Visual Studio and .NET SDK rather than relying on a general list. A quick check is to retarget a scratch project to another installed SDK and repeat a borderline edit to see whether the outcome changes.