Visual Studio Extension subscribe to a debugger event - c#

I'm developing a visual studio extension and now I'm facing a problem:
How do I subscribe to a Brake Point, i.e. every time the debugger catches the Brake Point, I would like to perform some action.
I can split this single problem into 2 problems:
1. How do I fire a function without pressing anything (I understand that the event should do this)
2. What function should I call to see the breakpoints (make my function fire)
(Don't see any reason to put any code because this is a HOWTO question and for real I don't have what to show)
Thanks for any help!!

You can use DTE.Events.DebuggerEvents and DTE.Debugger to receive notifications of a break point and get information about it.

Related

Locating an EventHandler through Application Usage C#

I'm converting a program from visual basic to C#, and in order to test it I need to change the configs so that when a menu option from a menu that appears after a right-click is pressed it calls the C# code I created rather than the old Visual Basic code. Obviously, that means locating the event handler. Unfortunately, I don't know the name of the menu option being pressed and have yet to guess what it is. Is there a way for me to run the application, and have the program pause (like a breakpoint) at the very first thing it does after the menu-option is pressed in the application? Right now I have a breakpoint on the first line of the method that is run. But is there a way to find the eventHandler that triggers that method, by running the program? Or is there another option to help me find what's triggering it?

Debugging: get path of execution

I was wondering if there is any way to return the path that Visual Studio takes when running through a program. For example, without setting breakpoints, is it possible to know exactly what happens when I click a button on a web app I created? Like if I clicked a button that had an action, is there some kind of info that Visual Studio can spit out that tells me what happened? (which functions in which files were used, etc. Essentially the "code path").
To add on to my question, I'd like to use something like this to help debug an issue. I want to know exactly what is happening when I perform some kind of action (button click in my example). If I know every "code path" I can better address the issue I'm having.
If I understand correctly your question, you're looking for Environment.StackTrace
The StackTrace property lists method calls in reverse chronological order, that is, the most recent method call is described first, and one line of stack trace information is listed for each method call on the stack. However, the StackTrace property might not report as many method calls as expected due to code transformations that occur during optimization.
Something else you can do is adding debug log entries to know what's is going on. It may be more useful since you could add extra custom data.
Not sure if you already have a log framework on your project. If you don't have any log4net could be a good option
Converting my comment to an answer so there is an answer that addresses the original question:
Use a performance profiler, which is designed to observe execution paths (typically to help you find bottlenecks, etc., but it will work fine for your purposes too). A good performance profiler will let you dig down and see, for any method, what methods it calls, how frequently, etc.
You can print out a call stack results to the output window in Visual Studio. You will still need to use breakpoints but the ones that doesn't stop the application. To do that:
Find the place in your code when you would like to get the stack printed out. For instance at the end of button clicked handler.
Place a break point there.
Right click the breakpoint. From the context menu select "When Hit..." option.
In the window that will show up select "Print a message:" checkbox. It will enable a textbox. In the textbox type in: $CALLSTACK.
Check the "Continue execution" checkbox if you don't want to stop the execution while printing the results.
I don't remember if the "When Hit..." option is available in the Express edition of Visual Studio.
There are also some other data you can print out without breaking execution, e.g.: previous function, process id, etc. The details are actually available in the "When Hit..." window.

getting the debugger to break at the next click event

in a .net windows forms project which has 100s of forms, and all those forms has countless custom made controls with base classes involved, its very difficult for me to know where a particular button is, i mean whats the form name which I'm looking at while i'm running the application, and where exactly is the button click event, in code, of the button that I just clicked. Is there a debugging feature in Visual Studio, which would just break the execution for me to the line where the click happened. Can I tell VS to break at which ever Click event comes next?
(running visual studio 2012/13 these days).
thanks.
Just before you click the button in the program do this:
Go to visual studio and pause the program. Just press the pause button.
Then press F11 (Step Into).
Now press the button in the program, and you should be taken into the event handler.
For web projects, the technique suggested by Jakob Olsen will not really work, because you have no active thread in between the calls, and hence no thread to resume upon the next action. However what worked for me was:
Find some code (any code in your app) you know for sure it gets executed and set a breakpoint
Trigger this breakpoint, use SHIFT-F11 to step out until you're out of all methods
Now do the action of which you don't know what code is executed, and it will break
I can suggest partial solution.
If your click events are named like "Button_Click", open Breakpoints windows while in debug and create New breakpoint.
Click OK and you will see list of functions. Check them and click OK. On every function that you have selected will be created a breakpoint.

In Visual Studio 2012/2013 is it possible to have breakpoints or methods listed automatically while debugging

I did some research on this before asking the question and since I might be asking it incorrectly, I might not have done the right searches here first.
What I am trying to accomplish is when I start to debug or run an application in Visual Studio, is to have the IDE show me what methods are executing when I do something in the GUI/application.
For instance if I click a button in the GUI labelled "Search", I want to see the chain of events/methods that execute for this process. This I am not sure of. I hope I have asked the question correctly. Thank you for your time.
Have a try with IntelliTrace.
Make sure IntelliTrace is enabled and call information is selected;
Launch your GUI application, and perform what action you want;
In IntelliTrace window, click Break All. If IntelliTrace window is not displayed, click Debug -> Windows -> IntelliTrace Event;
Expand the event you are interested, for example, 'Clicked Search', and click Call View link;
You can see call stack you are interested.
There are two ways to approach this:
If you have no idea where the code you are looking for is, then simply start your program with a Profiler such as JetBrains dotTrace. Then, get ready to push the button, click "Start Profiling", click the button, and then as soon as the operation is finished, click "Get Snapshot". Now, use dotTrace's Call Tree to see which methods called which. I use this technique all the time for just this purpose!
In this view, you can use the arrows key to navigate the method-calls tree.
If you have a general idea of which class[/es] get invoked when you hit the button on the GUI, but don't know exactly which methods are called, you can use OzCode's "Add Breakpoint to Every Method" on a class, so that even if you don't know the exact method that's about to be called, whenever the class is accessed, you'll break into the debugger and be able to explore.
Due Diligence Disclaimer: I am a co-creator of OzCode.
You can use the Runtime Flow tool (commercial, developed by me) to see the chain of events/methods in a .NET application for GUI actions.

Visual Studio is missing/moving my breakpoints

The problem is that when I place a breakpoint and debug/run, the breakpoint moves by itself.
Before/whilst coding:
After clicking run/breakpoint hit:
Breakpoints typically work ok for me, but it seems that they sometimes randomly play up. I first had this ages ago with a VB project, and in the end, I bypassed the problem by removing the breakpoint and adding it somewhere else where it was still useful.
Whilst I could probably do the same again, and this is only the second time it has happened (that I remember), I don't really want to have to and would like to know what is actually wrong.
I have read through many similar questions here, but I cannot see an exact match and the answers do not help. I have tried - building, rebuilding, closing/reopening and cleaning.
I only provided a picture of the bit of code where it occurs, if you need anything else, please let me know.
It's because the debugger isn't able to break at that point. For example, the debugger can't break on auto-implemented properties, or at the header of a method; instead, it breaks at the first line of the method.
Also check to see if you had set the breakpoints in one mode (Debug) but are now in a different mode (like Release). This caused me some momentary angst.
I got this problem after Windows had inexplicably added 6 months to the current system date (and 1 hour to the time). I didn't correct this right away, so builds made before the correction looked more recent to Visual. This lead to running the wrong (older) build when debugging.
Since I couldn't find a "Clean Solution/Project" option, I had to manually delete all .pdb files in the solution. The problem was instantly fixed. I just hope there aren't any more files I might need to delete (I'm new to Visual and don't know much about how it works behind the scenes).
You can get this if the breakpoint is AFTER a return statement. Visual Studio will bounce the breakpoint to the closing brace (or "End Function" for VB.NET) because return is jumping out of the function.

Categories