Using Edit and Continue Behavior

Visual Basic .NET offers some support for edit and continue behavior; however, by default edit and continue behavior is disabled for Visual Basic .NET. This is one feature of Visual Studio .NET that is a bit misleading. If you enable edit and continue behavior (ToolsOptionsDebuggerEdit and Continue) for Visual Basic .NET, you will be able to modify your code while debugging, but the most common response is that the changes are ignored until you restart. This can be helpful if it will prevent you from losing the changes you desire , but it may make debugging confusing since the line numbers in the code may not coincide with the references in the debug file.

The Visual Studio .NET help documentation under Edit and Continue, Limitations, describes four possible outcomes of using edit and continue behavior.

• The title bar flashes a message indicating the code is read-only.

• The changes are made in the code, but the debugger continues executing the old code, resulting in the discoordination between code and cursor positions during debugging.

• The changes are accepted, but the debugger stops and the code is rebuilt and restarted.

• The changes are made, but a dialog indicates that the changes cannot be made.

From the help files it is clear that edit and continue behavior is limited. The primary reason for this is that Visual Basic .NET is compiled instead of interpreted. It might be difficult to implement true edit and continue behavior in compiled code without recompiling. Fortunately, compiling even large applications does not take very long. In general, I use the edit and continue behavior to change code (rather than documenting changes to make later), but I usually have to restart shortly thereafter.