C++ Edit and Continue in Visual Studio 2015 Update 3 - C++ Team Blog (original) (raw)

We’ve been continuing to improve on C++ Edit and Continue (EnC) since we shipped it in Visual Studio 2015 with the default debug engine and the VC 140 toolset. We’ve addressed a fair bit of customer feedback and based on this, I’ll go over the latest developments in C++ EnC for Update 3 (download) and other clarifications in this blog post.

A quick recap – Edit and Continue allows you to modify your code while debugging (for example, if you happened to find a bug in your code at runtime), and the debugger will apply your code changes to the debugged process and continue debugging with your new code! This can help speed up your Edit > Build > Deploy > Debug cycle. Find out more info with our previous posts here and here on how to use C++ Edit and Continue.

Things we fixed in Update 3

Stale code (false positive) with EnC on static libraries: Making edits to source files in static libraries resulted in mismatching source information and stale code with a misleading solitary “Successfully applied code changes.” message. This issue has been fixed and now any stale code situation should include a warning explaining why we couldn’t remap the Instruction Pointer.
EnC Crashes/Hangs for large projects linked with /DEBUG:FASTLINK debug information: Since the linker switch FASTLINK leaves debug information in the obj files rather than consolidating it in the PDB, Visual Studio was running into memory issues with EnC on large projects, which is now resolved.
C1092 error/C4656 warning: We’ve fixed more reports of the infamous “fatal error C1092: Edit and Continue does not support changes to data types; build required” error for unrelated changes. Also, the compiler will not emit “warning C4656: … data type is new or has changed since the latest build, or is defined differently elsewhere” for false positive cases which caused compilation errors during EnC if you originally built with /WX (treat all warnings as errors).
Improved performance of “Applying code changes…” in EnC: We’ve chipped away at the time to apply code changes (i.e., when you see the dialog that says “Applying code changes…”) and made it ~3x faster!

Breaking Changes with Update 3

Allow Precompiling (Native only): The debug option Debug > Options > General > Allow Precompiling (Native only) is no longer supported with Visual Studio 2015 Update 3 and the default debugger. This is a legacy setting for a marginal performance improvement that has no functional impact.

Quick EnC reference

Requirements for C++ Edit and Continue

Build settings (project properties):
1. C/C++ > General > Debug Information Format: Program Database for Edit and Continue (/ZI)
2. C/C++ > Code Generation > Enable Minimal Rebuild: Yes (/Gm)
3. Linker > General > Enable Incremental Linking: Yes (/INCREMENTAL)
  Any incompatible linker settings (such as /SAFESEH, or /OPT:…) should cause warning LNK4075 during build (for example, “ignoring ‘/EDITANDCONTINUE’ due to ‘/OPT:ICF’ specification”).
Debugger settings (Debug > Options > General):
1. Enable Native Edit and Continue
  Any incompatible compiler or linker settings will cause an error during Edit and Continue (for example, “’file.cpp’ in ‘MyApp.dll’ was not linked with Edit and Continue enabled. Ensure that /INCREMENTAL linking is enabled, and the /EDITANDCONTINUE directive is not ignored.”)

Incompatible settings and unsupported scenarios

Debugger settings (Debug > Options > General):
1. “Require source files to exactly match the original version”: Having this option unchecked causes incorrect breakpoint binding after EnC in the modified functions, and so with Update 3 applying changes with this option unchecked will cause the error “The ‘Require source files to exactly match the original version’ setting under Debug->Options->General needs to be enabled for Edit and Continue. Please check this option and try again.”
2. “Allow precompiling (Native only)”: This option is no longer supported with Visual Studio 2015 Update 3 with the default debugger.
Windows 8/8.1 Store Apps: These projects use the VC 120 toolset and the C/C++ /bigobj switch. EnC with /bigobj is only supported in the VC 140 toolset.
Modifying lambdas passed to std::function: This will cause a genuine ODR violation and results in C1092.
Using a custom compiler (cl.exe) path: For security reasons, for recompilation of a file during EnC, Visual Studio will always use the installed compiler. If you are using a custom compiler path (for example through a custom $(ExecutablePath) variable in your *.props file), a warning will be displayed and VS will fall back to using the installed compiler of the same version/architecture.
FASTBuild build system: FASTBuild is not currently compatible with the “Enable Minimal Rebuild (/Gm)” compiler switch and so Edit and Continue is not supported.
Architectures/VC Toolsets: With the VC 140 toolset, the default debugger supports Edit and Continue with both X86 and X64 applications. Legacy toolsets support only X86 applications. Toolsets older than VC 120 should use the legacy debugger by checking Debug > Options > General > Use Native Compatibility Mode, to use Edit and Continue.

Logging

A frequent question we’ve received is about enabling logging if users run into issues with EnC. To help diagnose EnC issues, you can set the following DWORD registry value:

Visual Studio 2015: HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0_Config\Debugger\NativeEncDiagnosticLoggingLevel = 1
Visual Studio 2017 or newer: From a Developer command prompt, run VsRegEdit.exe set “C:\Program Files (x86)\Microsoft Visual Studio\[Version]\[YOUR EDITION]” HKCU Debugger NativeEncDiagnosticLoggingLevel DWORD 1

Setting this value (at the start of a debug session) will cause the various components of EnC to spew verbose logging to the Output > Debug pane.

Summary

We’d love to hear any feedback on Edit and Continue – you can reach us at vsdbgfb at microsoft dot com/in the comments below/through the Send Feedback feature in Visual Studio/via twitter.