When debugging a program in Visual Studio 2013 by using an external debugger plugin (such as VisualGDB) instead of the built in debugger, .natvis files are not loaded and used.
Is it at all possible right now to use NatVis with any other debugger than the built in debugger, and if so how does one enable this?
I do not believe what you want is possible. From what I can tell from having used VS's debugger and a couple external, integrated debuggers for various game consoles, it is the debugger's responsibility to collect the expressions for the scoped variables, and to display the proper values for them.
Your best bet would be to either use VS's debugger directly (if you can), or see if you can't get the developers of the debugger you're using to add their own support for type visualization.
Sorry!
Related
I want to write an extension for Visual Studio Code (VSCode) which will allow me to debug a C++ program with Visual Studio's native C++ debugger instead of gdb (which currently is the only option VSCode supports). I looked at the Visual Studio Debugger Extensibility. But it only explains how you can create a new debug engine and call it from Visual Studio as a front end. What I want to do is the opposite. I want to call the existing Visual Studio C++ debug engine from a different front end, which happens to be VSCode. There is no documentation on the Internet how I can achieve this. Can anyone please help?
I'm on the VSCode team. To use the VS debugger from VSCode, you will need to author a debug adapter extension. Here's some documentation on getting started, and here's the complete debug adapter protocol reference.
Try look at some existing implementations to get started:
Mock debugger – simple example debugger
Node debugger - node.js debug adapter
For C++, also check out C++ tools for VSCode.
Hope that helps.
Edit - Seems I misunderstood the problem. Here are some thoughts on consuming the VS C++ debugger from an external application.
To my knowledge, Visual C++ does not have public APIs or interfaces that allows external programs to easily interface with them. Other languages have better stories, since they often leverage external libraries or were designed with documented debugger protocols. The GDB machine interface is a good example of this sort of design.
My best suggestion is that you could try to leverage the Visual Studio Env.DTE interfaces to control VS programmatically. EnvDTE is not well documented and may not be exactly what you are after, but it is pretty powerful.
I am new to Visual Studio, so I am used to IntelliJ and Eclipse style of functioning. I usually do not use a debugger when I develop, so I do not want to use it in Visual Studio too.
Is it possible to disable all special debugging functionalities which Visual Studio provides when you start your application? I want to have only normal output for the errors. When I disable all debugging, then I do not have usual output too, so this is not an option.
I tried many settings, but nothing seems to work and give me the results I want - no extra popup windows, no shiny layout changes when you have an error, just ordinary output.
Thanks!
Everyone's definition of "normal output" is different. Personally, I like the way Visual Studio handles debugging.
The console window in Visual Studio is a debugger feature and hence that is why it doesn't work when it's not attached to the process. If you want a stack trace without attaching, you could use your language/framework's built-in facilities such as an Exception or StackTrace in the case of .NET. You could also have Windows write a crash dump, but then you are debugging the corpse inside of Visual Studio.
I am new to C# and wondering whether "windbg" or "Visual Studio Debugger" would be better tool for debugging managed code?
For the past couple of years, I have been doing development in C++ and I am comfortable in using windbg as compared to Visual Studio debugger. However, I am not sure whether windbg would work best in the case of managed code as well?
Is there any other debugging tool besides windbg and Visual Studio Debugger which works even better than these in debugging managed code?
WinDbg needs SOS or PSSCOR2/4 to debug managed code, but with either of those you get a very powerful debugger. However, I would not recommend using only WinDbg for managed code as support for source debugging is rather limited at the moment (and has been for a long time). You might also want to get SOSEX as it complements SOS/PSSCOR with additional useful commands.
In my experience Visual Studio works very well for regular debugging and WinDbg+SOS/PSSCOR2 is excellent for all those hairy problems such as memory issues, deadlocks and so forth that VS doesn't handle very well.
Are there gdb (or similar) for F#?
What tools/programs do F# programmers normally use for tracing F# code in Mono?
Does Visual Studio 2010 provides some integrated debugging tools for F#?
Visual Studio 2010 provides a fantastic debugging experience for F#, including breakpoints, tracepoints, call stacks, locals, stepping, set next statement, threads window, poking new values into variables, debugger visualizers, conditional breakpoints, immediate window, ... the only caveat is that the last two use the C# expression evaluator (F# does not have its own debugger EE), which means you must type e.g. C# syntax into the 'immediate window'.
(Everything I mentioned above is available for free if you download the free VS2010 Integrated Shell and the F# CTP.)
I am not sure what is available right now for Mono, but would not be surprised if there is something decent already, and something even better coming in the not-too-distant future.
Mono has its own debugger. The debugging format situation is slightly confusing because Visual Studio will generate pdb files which are needed for their debugger. Mono uses the alternative mdb format. fsc.exe (The f# compiler) will generate the appropriate ones for whichever platform it is run on.
The Monodevelop IDE can be used for general debugging of .net assemblies, even though it doesn't support a released f# version yet. You'll need to refer to your project's generated assemblies in the project.
Note that you also have to pass '--debug' to mono if you're executing it on the command line and want, for example, file names and line numbers in stack traces.
Any .NET debugger should work on F# code. The Visual Studio debugging experience is basically the same as for any other language (e.g. you can set breakpoints in the editor, etc.). I can't speak to what tools people use on Mono.
LinqPad understands F# code but I did not try it. A paid version gives you debugging.
I am using Visual Studio 2008. I don't need to debug some DLLs in my project, so can I disable symbol loading when debugging a Visual C++ program? Does it help to make startup time faster when debugging?
The symbols are all local, so I don't have those slow loading problem, just want to make debugging faster and faster.
For example I am using Qt libraries, when I hit "Starting Debugging", the Output window shows that the symbols for Qt libraries are loaded. If VS can stop loading those symbols, the debugging startup time should be faster. Of course, I still want VS to load symbol for my executable.
Just found out that Visual Studio 2010 actually do what I want.
To load only the symbol for your executable file, without loading other symbols (eg: DLLs):
Go to Tools->Options->Debugging->Symbols
Click "Only specified modules"
Clear "Always load symbols located next to modules"
Click "Specify modules"
Click the new icon
Enter your executable filename (eg: my-awesome-app.exe)
Also found out that Visual Studio 2010 seems to perform better than Visual Studio 2008 when debugging. At least the IDE layout switches back faster when the debugging is stopped.
I am not sure what you mean by 'startup'. I assume you are talking about the launching of the actual application. The time to launch the target application is expensive regardless of mode you launch it. It may be less in Release but that will be negligible.
Turning off all symbol paths as mentioned in the other solution is a viable option. However, I am not sure why you are debugging if you do not want symbols for your launched application. Without the applications symbols you will not be able to see where you are in the source code when you are debugging.
If you are looking for a faster debugging experience you can use WinDbg. It comes with the Windows SDK but can also be downloaded seperately. If is a faster UI than Visual Studio, but it is much more cumbersome to use if you are more comfortable with a GUI. WinDbg uses commands to perform almost all tasks, but you can do some great debugging and it is faster in many cases compared to Visual Studio. In the event you want to debug C++\CLI or any managed application (e.g. C#), I would stick with Visual Studio. There is an extension in WinDbg called SOS, but it requires some advanced debugging experience to use correctly.