Debugging with Breakpoints in Visual Studio

what's up everyone welcome to another episode of code porn today we're going to be looking at some debugging techniques using breakpoints in Visual Studio now breakpoints are a very important part of the debugging process because they give us a way to specify a specific stopping point in the execution of our applications now when these breakpoints are hit our application will stop executing and at that point is to do will take over and give us the ability to do things like examine data such as local variables run commands and control the execution flow of our application now the problem with breakpoints is not all developers know about breakpoints and how to use them they're still using techniques like message boxes or console dot write line and out of the developers that do know about very points and do use them they aren't aware that Visual Studio provides some enhanced features or advanced features for breakpoints that are very useful and that's what we'll be focusing on today so let's jump over to the demo so first things first I've got some demo code here let's go ahead and set a breakpoint to set a breakpoint we select a line that we want to stop execution on and then over here in Visual Studio we have this gray sidebar here we can click on that and when we do we see that our line has been highlighted with red and we've got a little red circle icon over here that lets us know that we have a breakpoint set at that current location and that breakpoint will follow that location as we navigate our code we can also do the same thing by selecting a line and pressing f9 it's just a visual studio shortcut and f9 to delete the breakpoint so now that we have a breakpoint we need to be able to manage them and we can do that in a breakpoint pane which is found under the debug menu under windows and breakpoints now inside this breakpoints pane we can see a list of all the breakpoints that we have within the entire solution that's currently open now at this point we only have one so let's go ahead and set another breakpoint okay now we see our new break point now what does break point pain does it gives us all the information we need about all the break points in the application and also gives us the tools that we need to manage them so we can delete break points we can delete all break points matching the search criteria we can enable or disable all break points this is handy when you want to run to the application but you don't want to hit any of the break points but you also don't want to delete any of the break points because you're going to want to rename them later and then to re-enable them we just click the button again we can also export the list of break points that we have this is useful if we're debugging a certain scenario with a certain set of break points and we want to be able to save those so that we can reuse them later on we can click this button here export those to an XML file and then when we're ready we can use the import button select our file and have those automatically loaded in for us now by default when you open up your breakpoints pane you're probably not going to have all of the columns that you see here so to change that you can click on the columns drop down and just pick and choose which pieces of information you want to see now at the moment we only have two break points but in a large solution it's very common to have many many break points but as you can see these aren't very useful they're not very helpful they tell you which file the break point is in the line and the character but that's not always really helpful what exactly is this break point therefore what is its purpose so we can help that by right-clicking on the break point we can also do that over here on the sidebar and choose edit labels and we can add some labels to our break points to make them more meaningful so in this case let's just say this is in the do work method but let's say this method is actually a hundred lines long and we have ten break points just adding that this is in the do work method is kind of helpful but not completely so let's add a little bit more information we'll just say console dot write line now here and you can put in whatever it is you want in this label it's just there to help you describe what this breakpoint is therefore click OK back on our breakpoints pane now we see under the labels column we have all of the labels that we typed in so not only do we know what this breakpoint is for we can also filter out breakpoints using the search box here let's type in do work and filter that out and now we only see the breakpoints that match the search criteria okay let's clear our search results now if you wanted to actually navigate to where this breakpoint is let's say we're in a different file somewhere else we can use this button here to go to source code and it will put our cursor in that file if the file is not open it will open it for us and then navigate directly to that line you can also just double click on them and now to do the same thing now again if you're in a different file let's say you're an app config but these breakpoints aren't in app config and you can see which files are located in over here on the file column and also by their name you can just double click on them and now to navigate you right to that breakpoint in the file that is located in ok well I want to run this application but I've got a breakpoint that I don't really want to hit because it's not useful and that's the one on the do work method call so I can disable that by just unchecking the box and you'll see here the difference here we've got two breakpoints this one is active it's a full red circle and this one up here has been disabled and we know that because it's now a hollow circle you can also click on the break point and it will re-enable it and you click once more and it will delete it but we just want to disable this one so let's go ahead and run and we see that we've hit our breakpoint down here and our breakpoints pane you'll see that now the breakpoint is bold this tells us that we're currently stopped at this breakpoint location now you notice over here we have a hit count column it says break always that means we're always going to break when this breakpoint is encountered and it gives us a count of how many times a break point was hit so if we continued once more now we see currently hit twice but this can be a problem because we are in a for each and we are going to hit this break point for every single item in the collection that were enumerated over and maybe that's the expected behavior that's a behavior that you want but in this case we have far too many items in our collection and we're only interested in stopping when item is something that we're interested in so we can configure this break point by right-clicking on it and setting a condition now in the condition pane we can type in any condition we want so we'll type in item is equal to Apple and then our options are is true so whenever the item is equal to Apple is true then the break point will hit we can also use has changed so that once the expression is evaluated if the result ever changes then it'll break so we'll just keep is true for now now we can also type in just regular C sharp code so we'll type in dot equals an item and you can see we get some intellisense because it knows what item is okay so we'll type in item equals apple now normally if we hit run we would hit the break point again and we're currently sitting on grape and grape is the second item in the collection but we want Apple so normally the next one would be orange so let's hit run and see what happens okay so we've had a break point again and now our item has Apple we didn't break on orange so the four-h code continue to execute and the break point expression was evaluated every time that it was hit but it only stopped execution when the item is equal to Apple which is what our expression is and then if we continue again we don't hit the breakpoint again even though there were two additional items so that's how we set conditional breakpoints now you notice that our icon has changed over here it's got a white plus symbol in the center of it and that's to denote that this breakpoint is conditional and you can also see that in the breakpoints pane now one thing that I want to point out about conditional breakpoints is they can be really slow so if you had a lot of code or you have a large collection that you're numerating over it's really going to sit on the execution because that breakpoint expression has to be evaluated every single time than it's hid so don't be surprised if your application starts to slow down okay so another type of condition that we can set is a hit counter so in the hit count configuration dialog we have a couple options we've got this drop-down here so we can set this breakpoint to break always so every time that it's hit it's going to break we can break when the hit counter is equal to and then we can provide a value we can break when the hit count is a multiple of or if it's greater than or equal to a number let's go ahead and just choose when account is equal to and we'll set that to four and then down here in this dialog you'll see the current hit count which is zero because we're not actually running and you can reset that if you want so let's click OK and then you'll notice that we still have down here we have a condition when item equals Apple and a hit count is equal to so let's go ahead and undo our condition by unchecking that okay so now when we run it we've hit the breakpoint and you'll see that the current hit count is equal to four and our item is now Kiwi let's go ahead and take off hit count so that'll break always another useful option is setting a win hit condition now in this dialogue we have an option to print a message now what this will do is it will actually take in this expression here and print that out to the output window this is really handy if you're trying to debug something and you need information like for example in our for each loop we want to know what the items are but we don't want to add any additional code like debug dot write line or console dot write line what we can do is type in a message now in this message we have a few different expressions that we can use we can actually print out local variables and we do that by wrapping them in curly braces so you can see we're wrapping item that'll be the value of the item in the for each we can also use some of these predefined macros down here and Visual Studio gives you a list of those let's just say we wanted to print out the actual method we would use dollar function and visual studio will resolve that to whatever the currently executing method is and then you have an option here you can continue execution so that means that the breakpoint won't actually be hit but will still print out a message or you can uncheck that and the breakpoint will be hit and also the message will be printed to the window go ahead and continue execution click OK now you'll see our breakpoint looks a little bit different now it's a red diamond instead and then our actual line of code is highlighted in black and then down here and our breakpoints pane you can see what it's actually going to do I've already got the output window open so let's start this and you can see now we have a list of all the items that we enumerated over it was automatically printed out for us every time that breakpoint was hit now in previous versions of visual studio I believe up until Visual Studio 2010 these were called trace points so if they look familiar that's because they've been merged in with the functionality of break points now another useful feature is the filter option what filters do is allows us to restrict when the break point is going to be set in certain processes and threads now this is very useful in cases where you want to set a break point for a certain piece of code that may be executing in a multi-threaded application but you're only interested in certain threads and so we can do that by specifying a thread ID or the thread name something along those lines but for this demo we're actually going to restrict the process name okay we do that we see we have another conditional breakpoint here now when you run this from Visual Studio we're not actually going to hit that break point now you can see over here that we have a broken break point for some reason and you can tell that always because it's a hollow circle with a explanation point icon next to it now the message says that the break point is not going to be hit because the filter as a condition that hasn't been satisfied and that's because we are currently in our vs host process so instead what we can do and we're just going to add a read key at the start of the application just to give us a chance to actually attach the debugger to it we'll rebuild this and then we'll run the process directly so what are tools attach the process and then we'll find our target process in our available processes list click attach and now you see that we have our breakpoints is not broken and our application will hit a key because that's the line that we're sitting on and now we've had our breakpoint because now our process is no longer running through vs host because we ran the process directly now since we're stopped at a breakpoint make a good time to show you the go to disassembly option will take you to the disassembly and navigate you to where the breakpoint would be equivalent to the line of code that we've broken on alright that's it for this episode be sure to subscribe to our channel follow us on Twitter and Facebook and visit code porn when you have nothing better to do if you have an idea for an episode or you want to be a guest on an episode send an email to code for NGO at gmail.com and let me know thanks for watching

Channel: Code Insights

Views: 108,760

Keywords: debugging, breakpoints, visual studio, .net, c#, csharp, Breakpoint, Microsoft Visual Studio (Software), visual studio 2010, visual studio 2012, visual studio 2103, visual studio 2015, debugging with visual studio, how to use visual studio, debug c# visual studio code, debug c# code, C# (Programming Language), Software (Industry), c0deporn, codeporn, dustin davis

Id: 7ab4z9u7Q_I

Length: 16min 15sec (975 seconds)

Published: Sun Jun 22 2014