One of the most useful features of the Visual Studio debugger is Edit and Continue (EnC), which works for both managed and native code (where native admittedly had some significant limitations in previous versions of Visual Studio through 2013). In this post I want to share some changes to EnC for C++ developers with Visual Studio RC, and also share our plans for VS2015 RTM.
First let’s look at the C++ EnC against x86-built targets, and then we’ll look at 64 bit.
C++ EnC x86
In Visual Studio 2013 you had to explicitly turn on edit and continue for native code because enabling it causes the debugger to fall back to the legacy (VS 2010) native debug engine. This means that you had to choose whether you were able to use new features such as natvis, async call stacks, and the Diagnostic Tools window or use edit and continue.
So in Visual Studio 2015 RC we’ve started the process of moving edit and continue support into the current debug engine so you’ll no longer have to choose which features you want. It’s important to note a few things about this RC release:
- This represents the beginning of this feature work and is very rough, but we’re excited about the capability so wanted to give you the opportunity to try it
- Because this is an early preview, it is still turned off by default.
- In support of the goal to enabled this by default once the feature is ready, we’ve modified the edit and continue UI by:
- Removing the “Edit and Continue” sub page
- Moving the options to enable it to the General debug options page
- Once the feature is ready to be enabled by default we plan to have it share a single “Enable Edit and Continue” option
So if you’d like to try out this early preview experience of the ability to edit and continue your code while debugging without switching debug engines you can check “Enable Native Edit and Continue” option under Debug -> Options.
Please note that errors are to be expected at this point at this stage, so if you rely on x86 edit and continue and need to continue to use the stable version that falls back to our legacy debug engine, you can access this functionality by additionally checking the “Use Native Compatibility Mode” (so both “Enable Native Edit and Continue” and “Use Native Compatibility Mode” must be checked).
C++ EnC 64 bit
One of our top customers request is to support edit and continue when debugging x64 C++ apps, which is not possible with Visual Studio 2013. As part of the work described in the earlier paragraph, we’re pleased to share that EnC x64 support as part of the default debug engine is currently in progress. Like the x86 support in the default engine, this is an early preview experience with many known issues. However we wanted to let you know that we are working on it, and also give the brave among you an opportunity to try it out (no prizes for making things crash or not work, it is expected at this point). If besides those warnings, you still want to enable it, you need to check the “Enable Native Edit and Continue” checkbox (same as opting in for x86 in the default debug engine) while also leaving unchecked ‘Native compatibility mode’. This means that once you enable edit and continue with the default engine, it will be available for x86 and x64 debugging. Additionally if you are using an existing project (so not created with Visual Studio 2015 RC) you’ll need to make sure it is using the “Visual Studio 2015 (v140)” Platform Toolset, and that the C/C++ -> Debug Information Format is set to “Program Data for Edit and Continue (/ZI)” (versions of Visual Studio prior to 2015 defaulted to “Program Database (/Zi)” for x64 which does not support EnC).
In summary, we plan for a single setting to enable/disable EnC for both native and managed, and it will work for both x86 and 64 bit – a simple story we are all looking forward to. In the meantime, with VS2015 RC, we have slightly more complicated options as described above, but also the opportunity for the bleeding edge among you to try our early EnC support in the default debug engine for both x86 and x64.
At this point if you have any comments or questions on our direction, let us know below in the comments section, through Visual Studio’s Send a Smile feature, send us a tweet, or in our MSDN forum. Although we’re not yet at the point that we are taking bug reports for this functionality as we are still working through a large number of known issues while working to finish enabling the capability.