Search

Cannot debug .NET 2.0/3.0/3.5 code using F5 in mixed mode from native c++ projects or c# project with 'start external program' set to native .exe by r w g

Closed
as Won't Fix Help for as Won't Fix

8
0
Sign in
to vote
Type: Bug
ID: 554067
Opened: 4/26/2010 8:06:24 AM
Access Restriction: Public
0
Workaround(s)
4
User(s) can reproduce this bug
For pure native c++ projects, when mixed mode debugging is selected in the properties of the startup project and the user presses 'F5', VS 2010 starts debugging for native and .NET 4.0 code - this assumption is not justified, since the user may want to debug native and .NET 2.0 code. There appears to be no way to configure VS or the project to start debugging in Native/.NET 2.0 mixed mode. There also appears to be no way to do this via the EnvDTE object model.

A similar problem occurs for .NET (c#) projects when the start action is 'Start External Program' instead of 'Start Project' - if the program is a native executable that loads .NET code at a later point, VS2010 will begin debugging in .NET 4.0 mode. Again there appears to be no way to override or configure this behaviour.



I am filing this as a bug because multi-targeting is supposed to allow you to target the older toolchains (vs2008 c++/.NET 2) in the new IDE. In the old IDE I can use F5 to start an appication in mixed mode debugging and debug native and .NET 2.0, in the VS2010 IDE I no longer have this ability.

The obvious workaround is to start the process without debugging and to then attach in the appropriate mode (native / .NET 2.0), but this has drawbacks (for instance you can't easily debug the programs start-up in this way).
Details (expand)

Product Language

English

Visual Studio Version

Visual Studio 2010

Operating System

Windows 7

Operating System Language

English

Steps to Reproduce

Setup a situation in which VS will be starting a native C++ executable that will later execute managed (.NET 2.0) code. Ensure that mixed mode debugging is enabled if starting from a c++ project.
Place a breakpoint in managed code that will be executed and start the executable using F5.

See attached zip for an example of a Native C++ MFC application (targeting the v90 toolchain) which creates a .NET 2.0 C# Com Object via Com Interop.

Load the solution from the zip file into VS2010 and build it. Set the MFC app as the startup application and enable mixed mode debugging in the project properties. Start the project using F5

Actual Results

VS starts the executable expecting to debug native and .NET 4.0 code - breakpoints in .NET 2.0 code are not hit, .NET 2.0 code cannot be debugged.

Expected Results

VS should be configurable to choose 'mixed (.NET2)' or 'mixed (.NET4)' debugging so that breakpoints in .NET 2.0 can be hit and the code can be debugged.
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey.

 

File Attachments
File Name Submitted By Submitted On File Size  
testdebug.zip 4/26/2010 69 KB
Sign in to post a comment.
Posted by J.Merrill on 9/6/2011 at 1:32 PM
It would be simple enough for Visual Studio to load the debugger that matches the target framework of the managed project whose "Start external program" setting causes a native EXE to load.

The problem with the workaround is that it will eventually cause trouble for anyone who puts it in but forgets to remove it at the point when s/he is working with .NET 4.

But it's apparently too late for any such comments to matter.
Posted by HelgeKlein on 1/5/2011 at 7:36 AM
I expect Visual Studio 2010 to select the appropriate debugger automatically.
Posted by Microsoft on 9/22/2010 at 10:12 AM
Hi rwg2,

We are resolving this bug as Won't Fix for Visual Studio 2010 because it does not meet our criteria for a servicing release at this time. However, this change has been added to our backlog for consideration in a future version of Visual Studio.

Thank you,
Visual Studio C++ Team
Posted by rbratton on 5/19/2010 at 10:15 AM
While there are workarounds (and they work in my case), I really would like VS2010 to be able to choose the correct debugger automatically.

thanks,
randy
Posted by ColinMyburgh on 5/7/2010 at 12:44 PM
The workaround does work correctly when the tag is present in the xxx.exe.config file.

I assumed (incorrectly) that MetaHostPolicy::GetRequestedRuntime would apply the <supportedRuntime> tag from the supplied ConfigurationStream.

Thanks for the suggestions!
Posted by Microsoft on 5/7/2010 at 9:47 AM
Hi Colin,

If the launch/attach scenario works for you, then the supportedRuntime tag workaround will behave in exactly the same way if it is configured correctly. Please see the following blog entry for more details: http://blogs.msdn.com/debugger/archive/2010/04/30/can-t-hit-breakpoints-in-a-plug-in-or-can-t-debug-net-2-0-3-0-3-5-from-a-mixed-mode-exe-project-with-visual-studio-2010.aspx

Please let us know if you are able to get it working correctly?

Best Regards,
Visual Studio Debugger
Posted by ColinMyburgh on 5/7/2010 at 8:43 AM
I have a similar problem, I have a unmanaged host that loads a number of .NET components. In VS2008 it was possible to set the host as the startup project and set the debugging mode to either mixed or managed only to debug both the host and managed components. On VS2010 the only way I can get to debug the managed code is to start the host outside of VS and then attach to the process. The workaround setting the supportedRuntime tag does not appear to work.
The behaviour is the same using the .NET 2.0 and .NET 4.0 hosting interfaces.
Posted by r w g on 4/29/2010 at 1:01 AM
Just wanted to say thanks for the suggestion - I have tried it out and it works.

Robin
Posted by Microsoft on 4/28/2010 at 4:31 PM
Hello,

Thank you for taking the time to report this, while we evaluate fixomg this issue, the workaround for is to add a <supportedRuntime> tag to your .exe's exe.config file.

For example, if I am debugging native foo.exe, I need to edit (or create if necessary) the foo.exe.config file in the same directory as foo.exe. I then add the supportedRuntime tag demonstrated in the example below:
Sample foo.exe.config:

<?xml version ="1.0"?>
<configuration>
<startup>
     <supportedRuntime version="v2.0.[version on your machine]" />
</startup>
</configuration>

This will let Visual Studio know to attach with the v2 debugger instead of the v4 default.

Best Regards,
Visual Studio Debugger
Posted by Microsoft on 4/26/2010 at 8:25 PM
Thanks for your feedback. We were able to reproduce the issue you are seeing. We are routing this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Sign in to post a workaround.