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.
Related
I'm quite new to VS Code. I have been debugging DLLs for 3rd party applications earlier in Visual Studio but it seems all the tools available there are not available in VS Code.
What I have been doing in VS earlier is:
create, develop and build my DLL to the plugins folder of that 3rd application (with references to the 3rd party application's libraries)
add the 3rd party exe as another project and set it as startup project.
when starting debugging session, VS automatically launches/attaches to my dll, i.e. I can step through my code when I start the plugin inside the app.
I am able to successfully build the DLL in VS Code to the correct folder and it works (will show me the simple msgbox i am waiting for). However, when I try to debug it by attaching the debugger to the 3rd party app process, the debugger does not stop at the breakpoints. When I hover over the breakpoint during debugging (which is not red anymore during debug), I get the message "No symbols loaded for this document". I guess I'm doing something wrong. The .pdb for the DLL is in that plugins directory. Is this because the debugger does not find it? Honestly, I'm not very well in with the launch.json contents yet (no need to work with those in full VS). What is the best way (if any) to do this kind of debugging in VS Code? In case this is something that definitely can't be done in VS Code, please let me know, so I know I need to return back to full IDE.
It turned out I just had some issues in my launch.json. I am now able to step through my code and the UX is practically the same than that with full VS. Problem solved.
#vernou Thanks for the link anyway!
I get an AccessViolationException when I run the Google Drive API sample in Visual Studio 2012 on Windows 7 x64. My project is targeting .Net 4.5. I get the exception on line 185:
await service.Files.Delete(file.Id).ExecuteAsync();
It happens in both Debug and Release modes, and in all platforms (x86, x64, AnyCPU).
It does NOT happen when I run without the debugger attached ("Start without Debugging").
It does NOT happen when I enable the "Enable native code debugging" in the Project properties.
Any ideas why enabling native code debugging might prevent the exception?
Note: running the sample requires the NuGet package (prerelease): Google.Apis.Drive.v2
EDIT: I wish Google people would chime in and tell if they've seen this as well because the sample instructions say:
Open the GoogleApisSamples.sln with Visual Studio
Click on Build > Rebuild Solution
Execute the .exe in Drive.Sample\bin\Debug
which is weird since they go out of their way to execute the exe directly from the debug folder instead of just saying "Run the sample".
It is just a shot in the dark, but I had a similar issue which turned out to be caused by the visual studio hosting process.
you can disable it and see if anything has changed.
You can do it from Project properties > Debug > uncheck the Enable the visual studio hosting service
I also had this problem although with a completely different project. for me the initial problem was that the wrapper library was a .net 2 assembly and my application was a .net 4 app. When i changed the wrapper to .net 4 i started getting stackunbalancedExceptions instead.
This turned out to because the callingconvention (and perhaps the charset) property for the DllImports was not set correctly. Once i fixed this i no longer get any exceptions in .net 4, however i still get them when compiling the wrapper library as .net 2.
There might be a compat settings that can make it work with mixed 2/4 framework, but since i was able to recompile i haven't really checked.
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.
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.