I have an .NET 4.0 application thats mostly in C#. It's got a managed C++ DLL that makes use of an unmanaged library. I'd like to debug the library from within ReSharper, but I'm on x64. If I use nunit and attach the debugger to the running nunit process everything works fine
is there any way to do what I need?
Actually there IS an issue with resharper here. We can debug in nunit, mstest and if we spin up out application and attach with a debugger. But basically no matter what you do you will NEVER get a breakpoint to hit in Resharper. And there is no error it just bypasses everything in the unmanaged code. There is at this point in time no solution that I can find that allows mixed mode debugging with resharper. Our organization struggled with this for several weeks. We eventually abandoned resharper for debugging in favor of plain mstest.
see the following:
http://devnet.jetbrains.net/thread/290349
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 have a WinForms managed application which calls into a native C++ dll. I have enabled mixed managed and unmanaged debugging for the project and I'm able to step into the unmanaged code when debugging the project.
I'm interested in JIT debugging because it's much faster to run the debug build outside the debugger and start debugging only after some assertion is violated. JIT Debugger works fine, when the exception is raised in the managed code. It also work when I JIT debug a standalone C++ application. But whenever an exception is raised inside the unmanaged code which is invoked from the WinForms application, the JIT debugger quits immediately after I initiate the debugging session. I have enabled all the JIT debuggers in Options/Debugging/Just-In-Time list. Is this scenario supported at all?
UPDATE
I've run some more tests, and I can see that
This problem is not specific to WinForms applications. JIT Debug also fails when a managed console application calls into a native dll, which raises an assertion exception.
The problem does not seem to depend on framework version. I tried versions 3.5, 4, 4.5, 4.6.
The debugger also fails to break on an assertion exception in the unmanaged code, when I attach the debugger to its managed host application.
I have gone through this situation before. I think the problem is that the exception is uncatched by debugger.
I did the following and maybe this would be helpful.
Click Debug->Windows->Exception Settings.
Or you just search "exception" at quick Launch.
You may find a lot of exception is not catched by default setting.
I feel stupid. The solution was right in front of me.
There's an option in Visual Studio Just-In-Time Debugger dialog. It's called "Manually choose the debugging engines". Both Managed and Native engines have to be selected.
The Context
We'd like to modify Roslyn and be able to debug it while compiling with it. Pre-VS2015 release, doing this was a painful process that didn't flow very well.
Our goal is to develop a C# variant compiler.
The Dream
Pre-VS2015, executing and debugging your modded Roslyn required the opening of a second VS IDE (experimental) set to use your modded Roslyn. This process wasn't straight forward to setup properly, and oftentimes would break your VS2015 installation.
Post-VS2015, is there a better setup and process possible to modify and debug Roslyn?
I have installed Visual Studio 2015 but it looks like I need more required bits. After that I'm unsure how to run the tests and try the changes in VS2015.
We have our current documented process of testing your own versions of Roslyn here. As long as you're on Visual Studio 2015 Update 1 or later (where we did all the work to support this), everything should work.
The executive summary of those instructions is if you now enlist into Roslyn, you can choose the "VisualStudioSetup" project and just hit F5 to run. That builds to .vsix files in your build directory you can also install. If you want to, there's a CompilerExtension project that produces a compiler you can build with.
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.
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.