Debugging all events in Visual Studio 2010 without setting break points

I am trying to debug a windows form application which has a large number of events: button presses, timers, etc..

Is there a way to catch every line of code being executed by the application without setting a break point?

edit: The program was not written by me, so I am unfamiliar with the code. I wish to step through the entire program, catching every line of code being exe开发者_开发知识库cuted. Setting break points in every event is impractical as various controls are created dynamically.

For debugging a button click without setting breakpoints:

1. Start the app with the debugger.
2. Get to the state immediately before the intended click.
3. Go back to the debugger and press Pause then F11 (Step Into) -- nothing will happen.
4. Go to the app and press the button -- the debugger should take over and drop you into the event handler.

Note: This will not work if Paint, any Mouse event, or probably some other events are handled. The debugger will drop you into those handlers any time you attempt the steps above.

If you're using the Ultimate edition of your Visual Studio 2010 you can use its new feature called IntelliTrace (previously Historical Debugger). This will allow you to do exactly what you want - be able to see all method calls and events that happened during execution of your program, and you'll be able to jump back to the event which you need.

To enable IntelliTrace, go to Tools → Options → IntelliTrace, and check the "Enable IntelliTrace" checkbox, and select one of two modes: "events only" or "events and call information", then run your application with a debugger (F5).

The difference between the two modes is that the latter uses the profiler to collect all runtime information, so you get a complete call stack, however you won't be able to use edit-and-continue features of the debugger.

You can find more in this series of articles, and of course, on MSDN.

You could also try a code coverage tool.

For example, if you have Resharper and dotCover, you can run your application (via the dotCover->Cover Application... menu item) and when the application finishes, dotCover will show you which lines of code were run in the VS IDE by highlighting them in green. Lines of code which where not run are coloured in red.

I don't know if there are other tools which do this, but it's an option.

I developed the Runtime Flow tool to solve exactly this problem - to understand a large unfamiliar .NET codebase via realtime function calls monitoring. It's similar to IntelliTrace, but places more emphasis on control flow than on debugging.

Why would you want to break on every line? This would be very onerous and time consuming. If you want to see the activity of your program as it executes, use a logging mechanism or Debug.Writeline to output information to the Immediate window.

You cannot trace lines of code, but you can use Trace.TraceInformation calls where you want to have an idea of what's executed. There's also Debug.Write. Both output will write in the output window of Visual Studio.

Another solution would be to add logging to your application, for example with log4net, but that may be overkill for your needs.

This isn't exactly what you're asking for, but in case you didn't know you can toggle an existing breakpoint on or off. In your case, you could add break points at key places throughout your code and just disable them when you don't want to debug them. That way, you'll be able to re-enable them later when you want to use them again.

Enabling/disabling is available through the Breakpoints window found under the Debug > Windows > Breakpoints menu (CTRL+D, B). You can also include "Function" and "File" columns in the window, which might help you identify which breakpoints are in the event handlers that you care about

Not really, but you can set one breakpoint and single-step (F10/F11) through the rest of the code.

Nope 'fraid not - you need to set each breakpoint yourself.

If it helps F9 is the shortcut key for assigning a breakpoint - just set a breakpoint on the start of each method and use step through (F10) / step into (F11) from there.