Switching to Managed Compatibility Mode in Visual Studio 2013
In Visual Studio 2012, we introduced a new managed debug engine that provides us the ability to more rapidly add new features compared to the older implementation. This can be seen by the number of features introduced in Visual Studio 2013 after only a single year including Managed Return Values, .NET 64-bit Edit and Continue, Async Callstacks Enhancements, and Improved Tasks Window to name a few. Unfortunately, there are still a couple scenarios that are not supported yet with the new debug engine, so in these cases you will have to switch back to the legacy engine.
To most Visual Studio developers, the current debug engine should only have a positive impact and you need not worry about what happens under the covers. While eventually we plan to completely replace the legacy engine, there are still
two scenarios where it is needed. In this blog post, I will show you how to switch to managed compatibility mode, which you should do ONLY if you have interest in the two scenarios that the current engine does not yet support.
- You are using a .NET language other than C#, VB, or F# that provides its own Expression Evaluator (this includes managed C++)
- You want to enable Edit and Continue (EnC) for C++ projects while mixed mode debugging
If these scenarios do not apply to you, there is no need for you to switch back to the legacy debug engine.
[DISCLAIMER] Enabling Managed Compatibility Mode will disable many features that depend on the current debugger implementation to operate. It is our goal in the future to completely remove the legacy engine from the product and hence remove the options discussed later in this blog post.
With the disclaimer out of the way, and only if you care about the two aforementioned scenarios in VS2013, please feel free to read on to find out how to enable the legacy managed debug engine through the global options, for an EXE project, during attach, and manually through the project file.
To switch back to the legacy debug engine globally, select Tools/ Options …
then check Use Managed Compatibility Mode on the Debugging / General tab.
The global option will force the legacy engine to be used for any launch or attach.
The exe project system is used when the user invokes File / Open Project, and then selects an existing exe file. To specify the legacy debugger engine, choose Project / Properties and then set the Use Managed Legacy Engine to Yes on the General project property page. This setting takes precedence over the Tools / Options setting.
Attach to a Process
To specify the legacy debug engine when you attach to a process, choose Debug / Attach to Process. window
Then click the Select button on the Attach to Process dialog.
On the Select Code Type dialog, make sure the right version of Managed code is selected, and then select Managed Compatibility Mode.
Through the .csproj/.vbproj file
Hand editing the .csproj/.vbproj, by adding the ‘DebugEngines’ property within ‘PropertyGroup’, you can force the project to use the legacy debugger engine. To enable managed compatibility mode, define the property like this:
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
IMPORTANT NOTE: If your project is using the Visual Studio hosting process (the default for many project types), you must disable the hosting process for this fix to correctly change the debug mode. To disable the hosting process go to the Debug pane on the project properties page, and uncheck “Enable the Visual Studio hosting process”
Additionally if you are using this with Managed C++ code and want to also debug native code you will need to add the native debug engine GUID (shown below) to the <DebugEngines> property delimited by a semicolon , manually setting the property overrides the options you can set in the UI including the “Enable native code debugging” checkbox. So the property should be:
We hope that if you require managed compatibility mode, one of the above options will meet your needs. We are currently working hard to enable these capabilities in the current debug engine.
If any of you have feedback or questions about this, please let me know in the comments section below or in our MSDN forum.