I've been seeing this in my Visual C# 2008 RSS Feed forever now:
http://lincolnfair.net/oldLincolnFair/mad.jpg
I'm pretty sure this is a VS 2010 only feature, but I was wondering if there is anyway to replicate this in VS 2008?
Similar to #Relster I have a code snippet with the following
#if DEBUG
if( node.Name == "Book" )
System.Diagnostics.Debugger.Break();
#endif
Where node.Name == "Book" changes based on the condition I want to test for. the #if DEBUG wrapper makes sure the checks never make it to release code.
This is also a lot faster than using the conditional breakpoints in Visual Studio. When you use the built in conditional bp visual studio has to break into the app, pause all the threads, evaluate the expression and determine if it is true each time it hits the breakpoint. In a tight loop this can be the difference between near full execution performance and running at a crawl.
You can do it in VS 2008 too. I'm sure there's many ways to do it, but one way is to right click on the red dot in the margin of an existing breakpoint & select condition..., then just give it a condition that evaluates to a bool and it will only break if that's true. The conditional statement should have access to anything that's in scope at the line where the breakpoint is set.
There's also other options in that context menu that allow you to filter what will cause a break (for example only certain threads), break based on the number of times the breakpoint has been hit, run macros when you hit the breakpoint, etc.
The other way to do this is make your own conditions and use a call to:
System.Diagnostics.Debugger.Break();
While it may not be as sophisticated as the VS2010 way of setting breakpoints, you can get the same effect with minimal code overhead. Just remember to take that stuff out when you build release code.
Note: In VS2008 and VS2005, you can set a conditional breakpoint by setting a regular breakpoint (F9 or double click in gutter), and then right clicking on that breakpoint to set the "condition...". The ability to set conditional breakpoints is NOT available in the VS2008 Express Edition.
Related
I am working with Visual Studio 2015.
I have a big c# class file with lot of properties and methods. I want to set breakpoints to all possible lines (set and get of properties, methods) at once. How can I do that?
You could add Debugger.Break() on the end of every single line. Therefore you could use the search and replace function of visual studio and replace \n with Debugger.Break()\n (Remember activating the regular expression option). This would cause the debugger to break at every single line, even though you won't have an indicated breakpoint.
I don't think that there's a method to add normal vs breakpoints to every single line though, due to the fact that it's quite useless, considering that you normally just step through the code with F11.
I think you are looking for this,
steps to follow:
1) Add a break point on the first line of code you want to debug.
2) Run the application.
3) When you want to run the next line of code, Select Debug | Step Into
4) Repeat step #3 for each line of the code
With vim (vsvim) you can set a breakpoint, move down a line, then repeat however many times you like, eg:
{Escape}qq:vsc Debug.ToggleBreakpoint{Enter}jq100#q
will set breakpoints on the next 100 lines
edit: here is example video, wouldnt let me embed gif https://imgur.com/SFhlEr7
Step Into(F11) or use the Debugger.Break() or add breakpoint directly would be the workarounds for you, of course, I suggest you use the Step Into(F11) which was much more convenient.
If you could use the latest VS2017 version, it has a new feature "Run to Click" which is also a better workaround for you during debugging.
Actually you don't have to debug every line code, that's also the reason I suggest you use this new feature.
Run to Click: Simply click the icon next to a line of code while debugging to run to that line. No longer set temporary breakpoints or
perform several steps to execute your code and stop on the line you
want. Now while stopped at a break state under the debugger, the Run
to Click icon subtly appears next to the line of code that your mouse
is hovered over. Move your mouse to the icon and click the button, now
your code will run and stop on that line the next time it is hit in
your code path. Turn it off from Debug> Options > Enable Run to
Click.
Reference:
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes
Open a feature request with Microsoft https://learn.microsoft.com/en-us/visualstudio/ide/suggest-a-feature?view=vs-2022
There should be a mode that visual studio can be put in so that it automatically stops on every line of code in a particular project. This would be VERY valuable when you attach the debugger to a pre-existing process and you don't know where in the app is the current point of execution is, ie: web apps where you do not know the entry point.
I know the title is a bit ambitious, but I am wondering if there is a way, after displaying a previous state in the call stack window (Visual Studio 2010) when debugging a C# program, to restart (like when hitting "Continue"/F5) from there.
This would be particularly useful to debug a lambda expression that generates an exception, as there is no way to move outside.
For a real OO code time machine, the historical state of all objects would need to be stored in memory, so I doubt it is feasible at this stage.
Now if the state of all objects has not changed much, then we could keep the current state and jump back in time (as a shortcut to doing the same thing with "edit and continue").
Some times, you can right click on a stack frame and choose "Unwind to here" (or very similar wording). It's not always possible, and I'm not sure what the necessary conditions are, but I'm going to make a guess as to what might prevent it:
A native code frame on the call stack in the middle
Being halted at a StackOverflowException (obviously, death to a process in any case)
Maybe lambda expressions or other things that prevent Edit-and-Continue from working (?)
Basically, anything "unusual".
Other than that, if it works, then there you go!
This is a bit kludgy but:
While viewing the previous state in the call stack window, open the disassembly window (Debug | Windows | Disassembly or CTRL+ALT+D). Now you should be able to create a breakpoint which will stop execution when you get back to that location.
If you don't care what else executes, press F5 and allow the code to run back to your new breakpoint.
Now right click on the statement you want to restart from and select Set Next Statement. Press F5 to restart from there.
If you do care about what else executes on your way back to the new breakpoint you could use Set Next Statement to set the program counter to the end of the function you are in and use Shift+F11 to step out of that function (thus not executing any of the remaining logic in that function). Repeat as needed until you get back to your new breakpoint.
Note the various dire warnings about using Set Next Statement
Edit 6/18 When I tested the above I was running Visual Studio 2010 Ultimate. I just checked Visual Studio Express C# and it does not support the Disassembly Debug Window. When I can I'll check Visual Studio 2010 Professional and update this answer again. If you have Visual Studio Ultimate then the Intellitrace suggestion by #Hans is maybe a better bet.
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 executed. Setting break points in every event is impractical as various controls are created dynamically.
For debugging a button click without setting breakpoints:
Start the app with the debugger.
Get to the state immediately before the intended click.
Go back to the debugger and press Pause then F11 (Step Into) -- nothing will happen.
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.
Is there any tool I can use to view the values of variables live as the code executes in VS?
Right now I can see them only when I keep a breakpoint.But,the problem is that the code works perfectly fine when I keep a breakpoint.it messes up only when it runs fast.
Any help would be appreciated.
Thanks
You can only view variables when you have a breakpoint, however you could just manually write the variable values to the Visual Studios Output window:
System.Diagnostics.Debug.WriteLine(variable);
I my opinion , rather than setting break points, you can use Debug.Write(yourVariable) under the Debug mode, so you can watch the value in the output windows.
Cheers.
Sounds like you need a conditional breakpoint. Aside from printing the values (console, debug output, trace) as the code runs there is nothing that will show you live data slow enough for you to see it. Put a conditional statement in detecting when the values are no longer valid and stick a programmatic break point on that.
Use Debug.Write to print out the variables. You can also use profiler.
All the aforementioned methods (dumping to console, using Debug.Write, custom logging, etc. etc.) to dump the contents of variables will do the trick .
From your problem description however (i.e. "...works fine with breakpoints, fails when left alone to run..."), it sounds like you have a threaded scenario with synchronization issues. If that's the case, inspecting the synchronization methods used might yield better results.
In visual studio 2010 (maybe in earlier versions, I didn't check) the conditional breakpoint can be set to print a variable value and continue running. It is done by right clicking the breakpoint and choosing 'When hit'. Then it opens a dialog in which you can specify what and how to print.
It worked fine for me in a native C project.
When stepping through my C# code line by line via F10, it takes the debugger over one second to get to the next line.
I've tried deleting all watches and breakpoints, but that did not make any difference.
Is this normal? It's been like this for quite a long time now, so I can't even remember if this was ever better. My development computer is a Quad-core machine with no background task activity and plenty of RAM left.
If it's not normal, what else could I try? It's still ok to work with, but a less sluggish user interface would be great...
What's likely happening is you have a variable in the call stack frame which has an expensive .ToString method. In 2008, the data for the call stack window is rebuilt on every step regardless of whether or not the window is actually visible. Part of building this window will call .ToString on the values which appear in the parameter list if they have an overridden .ToString. Try disabling implicit .ToString calls and see if that fixes the problem.
Tools -> Options -> Debugger
Uncheck the "Enable Implicit .ToString calls"
I have found that if you have the option to debug unmanaged code turned on, the debugger can take a while to step between lines even if you are only debugging managed code. Try turning that option off (Project > Properties > Debug > Enable Debuggers > Enable unmanaged code debugging).
I tried all of the above. Unchecking 'Show Threads In Source' button fixed it.
In my case, disabling "break all processes when one process breaks" (Tools/Options/Debugger) reduced the time to "step over" from 2-3 seconds to a fraction of a second.
I have no idea why this option had such a big effect on doing a single step over.
BTW, I suppose that disabling this option might cause trouble if you are using threads that are not independent from each other.
I once experienced slow debugging as I had set up VS to look for pdb files on a network share that didn't exist any more.
Check here : Tools - options - Debugging - Symbols - Symbol file (.pdb) Locations
I've heard of this kind of problem if the "Auto" window is open. Try closing that and see if your performance improves.
If you haven't already, you should probably also install the "Visual Studio 2008 SP1 debugging and breakpoint" patch. Note that this patch goes on top of SP1. The docs for the patch don't specifically address the slowness that you're seeing, but it's a pretty large patch, and you might get lucky.
Turn off the Enable address-level debugging option in Tools > Options > Debugging > General.
It made a huge difference for me.
Do you have a lot of Watch expressions set up ? They will be evaluated after between each step, and if they take time to run, you will notice it as a delay when stepping.
I was experiencing a 10 second delay after stopping C# debugging before being able to start C# debugging again. VS2008 would hang during this time with nothing clickable. There is now a 0 second delay after I disabled the Visual Studio hosting process in Project Properties -> Debug.