My setup:
Application.exe (Visual Studio 6.0 C++)
Component.dll (Visual Studio 2010 C#)
Application.exe uses Component.dll
I want to be able to debug my Visual Studio 6.0 C++ application and the Visual Studio 2010 C# component that it uses at the same time but I'm not sure if this is possible or not.
I tried to launch the application from Visual Studio 6.0 and attach to that process (Application.exe) in my Visual Studio 2010 component solution but when I go to attach to the process (Application.exe) it is greyed out. I tried switching the Attach To: to Native but this does not allow me to attach to this process. My Application.exe is still greyed out in the window.
Is it possible to do this and if so how?
There can be only one debugger attached to a process, that's why the selection is grayed out. You have little use for the VS6 debugger, it doesn't know anything about managed code. You'll have to debug this from VS2010. Right-click your C# project, Properties, Debug. Select "Start external program" and select your C++ .exe. Tick the "Enable unmanaged code debugging option".
Set a breakpoint in your C# code and press F5 to start the .exe. The breakpoint indicator will turn solid as soon as the C++ code loads you DLL. Debugging the C++ code might be possible too although you're working with a .pdb from the previous century. You cannot single-step from the managed code into the C++ code, you have to set a breakpoint.
You cannot attach two different debuggers to the same process.
Instead, you can attach it only to VS2010, but attach it as both managed and native.
Related
So I'm now using Visual Studio 2019 in C# .Net Framework.
I have been programming in Visual Basic 6.0, and when I pressed F5 the IDE run and if there were errors while debugging if I pressed the X to close the Vb6.0 IDE. a message box prompted saying if I wanted to save the changes since there were errors while debugging I pressed no.
Now in Visual Studio 2019 using C#, that doesn't happen. If I press F5 and an error occurs while debugging, it autosaves the solution with its error. How can I stop it from saving with the error in it?
No, you can't debug code that hasn't been saved with Visual Studio. If you want to see the process it goes through, do this:
Open Tools -> Options
Click "Projects and Solutions", then click "Build and Run"
Change "MSBuild project build output verbosity" to "Normal" (or, if you want to see a lot of stuff, "Detailed" or "Diagnostic"
Rebuild your project
You'll see VS invoking the compiler and passing the paths to each of your file (and to all of your references) to the compiler. It needs to save and to compile and then execute your code.
The VS debugger is a full Windows debugger. Open Windows Explorer, double-click your EXE. Now open VS, in the Debug menu, choose "Attach to process" and choose your running EXE. You are debugging it (you can attach to any process you have rights to, but attaching to a debug build where symbols are handy give you the best experience).
BASIC and pre-.NET VB started their lives as interpreted languages. A pre-processor would take your source and convert it to tokens. Then an interpreter would interpret those tokens as it ran your programs. Though the last few versions of traditional VB could compile your code to an EXE, that interpreter was still there.
In particular, the debugger used it. When you ran the VB6 (and earlier) debugger, the debugger didn't debug your program, it debugged your source - injecting itself into the interpreter, not attaching itself to the EXE. That's why the behavior you are asking about worked.
As I mentioned, getting a Source Code Control system set up (which is always a good idea) will help you get close to what you want. Git's probably the easiest to set up. Visual Studio Team Foundation Services (or whatever it is called this month) is also a possibility.
I am writing C# plugin (DLL library) for a native\unmanaged application. The problem is that when I start debugger, the application runs and almost immediately exits (probably because my DLL is not loaded on application startup, but later). Checking "Enable native code debugging" helps, but significantly slows down application performance which is undesirable, because I only want to debug my C# code. Is there any way to debug DLL without enabling that option? I'm using Visual Studio 2015 Community.
I've figured it out. :)
Enable "Use managed compatibility mode" in Options->Debugging->General.
Enabled "Enable native code debugging" setting in 2010/2013 and verified debug symbols are loaded. Cannot step into the C++ source. After running the same project in VS2013 (without changing any settings), code steps into the C++ source. Why?
Note: This is being run from a c# unit test project.
Having the PDB file next to the DLL is not enough to debug the DLL.
You will need to have access to the DLL code so that you can step into it from your debugger.
Have a look at that thread:
http://social.msdn.microsoft.com/Forums/en-US/69e84750-6636-4656-bbd4-8d3586290af3/how-to-debug-native-c-dll-from-c-application?forum=netfxcompact
I have an old DLL written in Visual Studio 6 which I am calling from C# written in Visual Studio 2010. The DLL is not working properly and I want to debug into it. How can I do this? I have the source code project but cannot see how I can step into it.
Note: When I say "doesn't work", the call to the DLL succeeds and it gets a little way through the code in the DLL before failing, but I want to track down exactly where.
The technique of debugging a DLL is described here on MSDN. You'll need to do this from Visual Studio 6 (i.e. the tool that developed the DLL) and so the terminology will have changed. But the principles remain the same.
Attaching VS6 debugger on the .NET process shall work, as long you have the PDB file with the corresponding binary and the sources. You can break only on DLL code, however.
Attaching another VS+ shall work if the flag "Allow unmanaged debugging" is checked, but there is a possibility that symbols are not loaded by the debugger. A recompilation of the DLL shall solve the last problem.
Open Visual C++ Dll project, set breakpoint where you need. In the Project properties, Debug, Executable for debug session, type .NET executable file which uses this Dll. Start debugging (Go). When VC++ function is called, debugger breaks. Using this way, you can debug only unmanaged VC++ code.
Another way is to start debugging from .NET client in mixed debugging mode. Add VC++ project to the solution and rebuild it to debug both managed and unmanaged code.
Visual studio tells me that 64-bit managed+unmanaged code debugging is not supported. Has anyone managed to resolve this problem?
I've seen this problem too with the 64-bit debugger. Do you definitely need to debug both at the same time?
If not, when you need to debug native code you could run the managed application and the attach the debugger manually selecting "Native Code" as the debug type (as opposed to Automatic which might select both Managed and Native).
Ctrl+F5, once running,
Debug->Attach to Process.
In the attach to: box select "Native code".
Make sure in the processes box your vshost app is highlighted.
Press "attach".
Now your break-points in your native cpp code should trigger and the debugger will kick in.