We previously announced that we were working on support for Edit and Continue for both x86 and x64 in the default debug engine in Visual Studio 2015. Today we’re pleased to announce that Edit and Continue (EnC) is enabled by default in Visual Studio 2015 RTM. As a quick reminder, EnC enables you to make changes to your code when you’re stopped in the debugger, and have those changes applied when you continue execution without the need to stop debugging, recompile and run the application back to that location.

In Visual Studio 2015 we’ve made great progress on satisfying this top customer request, so in this post I’ll walk you through the current state of Edit and Continue including what doesn’t currently work and when we hope to enable it.

How do I use Edit and Continue?

Edit and Continue will work with the default project and debugging settings for new C++ apps, but there are a few things to check since projects created with older versions of Visual Studio might not have the correct settings. If you upgraded a machine from a previous build of Visual Studio 2015 (e.g. you installed RTM on top of RC as opposed to uninstalling the previous build and then installing RTM) the debugger setting will not be enabled by default:

• The Debug Information Format needs to be set to “Program Database for Edit and Continue (/ZI)”. If this option is incorrectly set the debugger will ignore the edit, it will be just like modifying a file with edit and continue disabled.

  

  
  If you make an edit in a binary not compiled with this option, the debugger will ignore the edit and you will see an error message when you continue execution “The source file has changed. It no longer matches the version of the file used to build the application being debugged.”

• Enable Incremental Linking needs to be set to “Yes (/INCREMENTAL)”. Note: Using the linker flags /OPT:ICF, /OPT:REF, or /SAFESEH will disable incremental linking.

  
  If this option is incorrectly set and you try to make an edit while debugging you’ll see an error message along the lines of “Edit and Continue : error : Failed to map memory for the edit on the debugged process. Out of reserved address space in module [some module path]”

• Enable Native Edit and Continue needs to be enabled under Debug -> Options: This should be enabled by default in 2015 RTM but if Edit and Continue is not working check the setting. Additionally as previously announced it remains our long term plan to unify this setting into the single “Enable Edit and Continue” checkbox

  

If those three things are correctly set, you should be able to use Edit and Continue with your x86 or x64 project with the exception of the known limitations in the following section.

Known Limitations

While we continue to work hard to improve the Edit and Continue experience, here a few important limitations to note regarding what doesn’t currently work and our plans around the limitations:

• Editing binaries compiled with /bigobj (e.g. this is used for Windows Store apps). If you try to make an edit in a binary compiled with /bigobj you’ll receive an error message stating that “Edits were made which cannot be compiled” (the output window will contain the error message “cl : Command line error D8016 : ‘/bigobj’ and ‘/ZX’ command-line options are incompatible”). You’ll then have the option to go back and manually modify the file, ignore, or have Visual Studio revert (undo) all of your changes. This is something we plan to fix in a future update to Visual Studio 2015.
• Editing binaries linked with /DEBUG:FASTLINK debug information. If you attempt to make an edit in a binary compiled with this you’ll receive an error message “Edit and continue is not supported for this binary. The binary was linked with /DEBUG:FASTLINK which is not currently compatible with edit and continue. Use /DEBUG instead”. This is something we plan to fix in a future update to Visual Studio 2015.
• Binaries support a limited number of edits: In order to support Edit and Continue the compiler reserves empty space in the binary that updated code is written into when edits are made (the /ZI flag is what tells the compiler to do this). That means it is possible to fill up the reserved space after multiple edits (the space used by each edit will depend on the scope and magnitude of the edit, it’s not deterministic simply based on a supported number of edits). If you run out of reserve space in the binary you’ll see the error message “Failed to map memory for the edit on the debugged process. Out of reserved address space in module ‘[module name]’.”. We plan to add the ability for you to increase the reserved space if needed in a future update to Visual Studio 2015.
• Edit and Continue is not compatible with optimized code: EnC is not currently supported in binaries compiled with optimizations. We are working on a workaround to unblock this scenario in a future update to Visual Studio 2015.
• EnC for x64 should only be used when building the binary with the x86_x64 cross compiler: For our first update we plan to use the native x64 compiler if that is what you originally used. However in RTM, EnC always uses the cross compiler, so it’s not recommended to try to use EnC with a binary compiled with native compiler as the changes will be compiled with a different version of the compiler than the original binary.
• Edit and Continue for x86 requires the project to use the v120 or 140 toolset it is not currently supported for older versions of the toolset. You can use EnC for x86 with older versions of the toolset by enabling “Native compatibility mode” under Debug -> Options.  We do not currently have plans to change this, but do let us know if it is an impactful limitation.
• Edit and Continue for x64 requires the v140 toolset: Supporting x64 EnC required significant updates to the compiler so it is not possible with prior versions of the compiler.
• Adding or modifying global or static variables. If you try this you will see an error message that “Edits were made which cannot be applied while debugging”. You’ll then have the option to go back and manually modify the file, ignore, or have Visual Studio revert (undo) all of your changes. Support for this is not currently scheduled.
• Editing binaries linked with Safe Structured Exception Handlers (/SAFESEH). If you try to make an edit with this incorrectly set, you’ll see an error message along the lines of “Edit and Continue: error : Failed to map memory for the edit on the debugged process. Out of reserved address space in module [some module path]”. Support for this is not currently scheduled.

Stale Code

If you make an edit in a location that supports Edit and Continue but for some reason the edit cannot be applied you’ll see the message “Changes were made that could not be applied. The debugger will show you the original source code that is currently executing”

The debugger will then open a read only version of the original source file so you can see the actual code that is executing.

There are several situations where you can encounter the stale code scenario:

• If the edit was not able to be compiled you’ll continue to see the original source file in the stale code editor for the remainder of your debug session. For example, this will happen if your edit results in a compilation error (the error list will show you the compiler error).
• If the edit was successfully compiled but the debugger was not able to update the process to execute the new code rather than the originally compiled version. If this happens you’ll see the stale code editor while that function continues to execute, the next time the function is called the updated code will execute and you’ll return to the standard editor and continue to have the ability to make additional edits. For example, this can happen if you add or remove a local variable that requires construction or deletion earlier in code execution than the current instruction pointer location (indicated by the yellow arrow in the breakpoint margin).

Summary

In summary, we discussed that Edit and Continue is now available for C++ applications including x64 without the need to change debug engines which means you still have access to features like natvis and async call stacks while using EnC! Additionally, we looked at the limitations with the feature in Visual Studio 2015 RTM and which ones we plan to address. Please try out the capability and let us know how it is working for you in the comments section below, through Visual Studio’s Send a Smile feature, or send us a tweet.