I have a requirement for developing a debugger extension for Visual Studio. The code is in C++, however, it is run in a simulator environment. The application is capable of receiving break points and displaying variable information.
I have looked into the Concord API, but it seems rather complex. Do I have to develop an Expression Evaluator, even though the code is in C++?
Basically I just want the program to run and hit the breakpoints that the user has created for starters.
Should I try and write a visual studio extension instead? Although I don't see any way of halting execution of a program in debug mode?
Thanks
Ah the joy of writing a custom debugger! I'm writing one now. See the visual studio custom debug engine sample to start with. Python Tools for Visual Studio, MIDebugEngine are more complex but also more complete and production code. Much easier to write the debugger in C#.
Some blogs that helped me a lot.
https://limbioliong.wordpress.com/2011/08/30/creating-a-com-server-using-c/
https://blogs.msdn.microsoft.com/jmstall/2009/07/09/icustomqueryinterface-and-clr-v4/
VS2005 SDK PDF has more detailed debugger documentation.
VS2015/17 C# Extension projects has a custom project type package which comes with a script debugger launcher to start with.
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 downloaded Visual Studio Community 2015 to try and lean F#. My F# projects compiles without any issues but when I try to launch the console project (even the default console project) Visual Studio just hangs and then freezes. The only way I have to shut it down is to go to the task manager.
Same thing if I try to directly launch the generated .exe file: explorer freezes and I have to go to the task manager to restart it.
All my C# projects work fine...
I have seen a similar behavior before on a machine that had an anti-virus installed. The anti-virus was blocking Visual Studio from running F# code with debugger and disabling the anti-virus resolved the issue.
In general, there are a few ways to run F# code in Visual Studio:
Using F5 to start the program with a debugger (this is the one that the anti-virus was blocking); F11 which steps into the debugger was also not working
Using Ctrl+F5 which starts the program without a debugger - this should work!
By creating an F# script file (Script.fsx), selecting code and using Alt+Enter to run code using F# interactive - this should work too.
Many people do quite a lot of work with F# using F# Interactive, so learning how to use that is a good skill, but to use the debugger, disabling anti-virus should do the trick.
When Roslyn installed, it comes with a couple of great demo tools. Firstly, the most valuable I think for those who want to learn syntax trees more thoroughly is the Syntax Visualizer Tool Window which shows the syntax tree of active *.cs files.
Everything worked fine when I launched this extension and tried it in a test instance of Visual Studio. But when I have installed this extension, it's not working anymore. I still have View -> Other Windows -> Roslyn Syntax Visualizer but just an empty window tool pops up.
Does anyone have the same problem and know the solution?
I guess that maybe I need to copy DLL files which this extension produces when rebuild but I don't know where should I put it.
Later I found another interesting detail - when I launch my own extension, Syntax Visualizer Tool works! So, it works only in test instance of Visual Studio. Why it should be like that?
The Syntax Visualizer only works when you are running Visual Studio with Roslyn enabled. When you start a test instance of Visual Studio, Roslyn is automatically enabled. Manually starting Visual Studio with Roslyn can be done by adding /rootsuffix Roslyn to the shortcut, but take care that Roslyn is not finished yet. It might not be advisable to enable it by default, depending on what you are working on. Of course, you can also just create another shortcut with Roslyn, so you can choose which one you want.
If you see [Roslyn] in your code tabs in Visual Studio, then you can use the visualizer. Another way of verifying if Roslyn is enabled is to view your extensions. The Roslyn Language Services has to be there for it to work. If this is not the case, then the visualizer can be opened, but it won't show any contents.
You can find more information about the visualizer extension here.
Nico most likely has the answer. Look in the Debug properties of the Syntax Visualizer project to see that it is launching with /rootsuffix Roslyn. Also, without launching this way, you should be able to see the Syntax Visualizer in the C# REPL and C# Script editor windows; as these are Roslyn CSharp editors.
When working in VS, the error messages in the bottom panel are compiler errors and warnings, right? Does this mean the app is being compiled all the time? I would expect those to appear only when trying to run the app.
This is probably a silly question, but I cannot find the answer.
Visual Studio continually parses the source code; this allows it to preemptively report some errors before you actually compile the source.
This is, of course, dependent upon which language you are using. C++ didn't get preemptive error reporting until Visual Studio 2010.
Visual Studio doesn't natively continuously compile code.
However, I just downloaded the 14 day trial of this little app called .Net Demon that's a plugin for Visual Studio. It costs $30, but definitely a nifty tool if you've got large solutions with many projects.
http://www.red-gate.com/products/dotnet-development/dotnet-demon/
I'll probably end up breaking down and buying it, it's pretty slick.
Each programming language is different (each provides a Visual Studio 'language service' specific to that language that provides the feedback), but for the most part, yes, it is being compiled over and over. In F#, for example, the compiler is divided into a few stages, main ones being lexer/parser, typechecker, and code generator, and the lexer/parser/typechecker are running inside VS, and every time you type a character into a file, that file is re-run through those stages of the compiler.
When you compile an application there might be errors and warnings which will be shown at the errors window. When you run the application errors will no longer be shown in Visual Studio but depending on how your application is organized it will either crash or handle them gracefully. Also notice that if you try to run the application with F5 or Ctrl+F5 Visual Studio will try to compile it first and if there are compile-time errors and warnings they will be shown.
I would like to control options on the debugger without using the debugging GUI's, preferably from inside the code being debugged. I would think that would be quite difficult, but maybe my debugged code can request a service from independent code that will communicate with the debugger.
This relates to another question of mine on controlling when to break on exceptions.
You can write Visual Studio macros that can do anything the GUI can, but they can get rather involved. See the MSDN documentation on Automation and Extensibility for Visual Studio
Doing this from the code being debugged would be tricky, you would definitely need some new form of communication with VS, maybe a custom add-in. I don't think an independent service would fundamentally help here. The biggest problem is that your code will stop running when the debugger breaks.
I know that you can do it with WinDBG and OutputDebugString, but for Visual Studio, I think you have to spool off another process, pipe commands to that, and have that manipulate the Debugger API.