Switching to Managed Compatibility Mode in Visual Studio 2013

Switching to Managed Compatibility Mode in Visual Studio 2013

Rate This
  • Comments 40

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.

  1. You are using a .NET language other than C#, VB, or F# that provides its own Expression Evaluator (this includes managed C++)
  2. 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.

Global Options

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.

EXE Project

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:


In Closing

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.

Leave a Comment
  • Please add 7 and 3 and type the answer here:
  • Post
  • Well, there may be at least one more scenario where the Legacy debug engine is needed. If I set a break point in my C# Project loaded dynamically in its own app domain in a self hosted WCF service, all watches say 'Could not evaluate expression'. If I turn on Managed Compatibility Mode, all watches show values as expected.

  • @Eivind Gussiås Løkseth

    Sorry for the delay in answering. That looks like a bug, I'll take a look today and let you know!


  • @Eivind Gussiås Løkseth

    Can you open a bug on connect.microsoft.com/VisualStudio and attach your solution and repro steps as well? I'm not able to repro this, but I'm not sure my app is similar to yours or if my repro steps are similar to yours.

    If you don't want to go through the process of opening a bug, you can email me at vsdbgfb@microsoft.com and I can set up a workspace where you can upload the project.

    Thanks a lot!


  • I was having the exact same problem as Elvind and also had to switch this option on.

    Please review:



  • @ewolfman

    We have released a fix for the issue you are describing in Update 2 CTP 2 - go.microsoft.com/fwlink

    Please let me know if that doesn't resolve your issue!


    Maria - Visual Studio Debugger

  • Just installed VS 2013 RC 2, but even simple breakpoint conditions such as "a".Contains("b") result in “The condition for a breakpoint failed to execute” every time the breakpoint is hit, forcing me to switch to Managed Compatibility Mode...

  • Is there a way to see which debugger(s) are currently in use in the current session / process?

    Can I force a C++/CLI project to use the same engine as I get when debugging a C# project?

    What other GUIDs can we put in the DebugEngines property?

  • @ pjotrb

    I've just verified this in VS Update 2 RC and I'm able to set conditions.

    Very simple conditions like the ones below work.



    For more help with setting BPs:

    you can check our blog post on BPs blogs.msdn.com/.../breakpoints-in-visual-studio-2013.aspx

    MSDN documentation: msdn.microsoft.com/.../5557y8b4.aspx

    Help on expressions to use: msdn.microsoft.com/.../za56x861.aspx

    If you are using the right syntax and still not able to use it, I would try a repair and restart, maybe something got broken in your install. Let me know if that doesn't succeed either!

  • Tried a conditional breakpoint in VS2013 Update 2 in a VB project on both Integer and Decimal variables and the Integer (i = 0) it can handle, but d=0D cannot be evaluated:

    The condition for a breakpoint failed to execute. The condition was 'd = 0D'. The error returned was 'Evaluation of method Microsoft.VisualBasic.CompilerServices.Operators.ConditionalCompareObjectEqual() calls into native method System.Decimal.FCallCompare(). Evaluation of native methods in this context is not supported.'. Click OK to stop at this breakpoint.

    So I'm guessing there is still a lot of stuff left to implement in the new debugger.

  • @ Ignisdivine

    Thanks for the feedback! This is indeed a limitation of the new engine. We are investigating this issue internally right now.


  • @ Ståle L. Hansen

    You can look in the Debugger/Processes Window, to find out which debug engine you are using

    If you have Managed Compatibility Mode enabled, we will use the old engine, and show it as such: Managed Legacy (v4.5, v4.0)

    If you use the default (new engine): Managed (v4.5, v4.0)

    Not sure what you mean by forcing the use of the C# engine when you debug C++. By default, you will be using the same debug engine in both cases. If you want to use EnC in C++ though, you need to enable it and use the old engine, as that hasn't been ported there. Depending on the project language, the engine will choose to enable managed/native/mixed/script debugging. But I don't know why you would want to go the managed path for a native project, as that won't bring you anything extra, it will actually take away as it's not able to handle the native cases.

  • @ Ignisdivine

    I'm happy to let you know that the issue you have submitted is now fixed and will be available in our next release

  • I can confirm that programmers at our company are still seeing the issue with Update 2. By "next release" I assume you probably mean Update 3 when it becomes available.

  • @Wray Smallwood

    If you are referring to the issue Ignisdivine pointed out, that one has been fixed for our next major release of Visual Studio, not an update, since other changes are happening in expression evaluation for that release.

  • Hi @Maria does your fix for @Ignisdivine also fix other decimal conditionals? I'm getting inconsistent debugger errors depending on what I use in my debug condition:

    r <= 0       Evaluation of method System.Decimal.op_LessThanOrEqual() calls into native method System.Decimal.FCallCompare(). Evaluation of native methods in this context is not supported.

    r < 0          An internal error has occurred while evaluating method System.Decimal.op_LessThan()

    r < 0M       An internal error has occurred while evaluating method System.Decimal.op_LessThan()

Page 1 of 3 (40 items) 123