Diving Into Visual Studio 2015: Debugging Improvements (Breakpoint Configurations and New Error List) - Day 5

In the following Program class, we are just fetching all the products and creating a new list of products for a new entity named ProductCodeWithPrice, where we list only the product code and price of products.
Now let us say we are debugging the code while a new product list is created and we want to place a breakpoint after a new ProductCodePrice instance is created in foreach loop.



When a breakpoint is put at line 27, notice the new inline toolbar. From here I can open the Settings or Enable and Disable the breakpoint. When we right click on the breakpoint to open the context menu, we see a new simplified context menu with most of the options that use to be presenting there now moved to settings option.



Let's again check the inline toolbar. Let's pick the Settings option. Notice that the settings now appear in a peek window instead of a modal dialog window. This helps a developer to easily modify the settings while debugging.



Conditions

Let's try to explore how conditions work. When we place a breakpoint and open the settings window, it shows options for Conditions and Actions and also mentions the location of breakpoint with the details like file name, line number and character position. Clicking on conditions checkbox shows some other options on how a condition can be configured.



The default is Conditional Expression, but there are two other options as well i.e. Hit Count and Filter. Hit Count option is used when there is a need that an execution pause is required at a particular iteration in the loop.

The second drop-down list is used to validate the condition. In this case, we have placed a breakpoint after prod object is created in each iteration.



Notice that we could pick Is a multiple of, or greater than or equal to validate the Hit Count.

Let’s suppose there is a scenario where we need to pause the execution and check the products list values after 3 iterations. So we choose Hit Count option as condition and “Is equal” to option in the second dropdown and in the text box near to it, type 3. This means that when the loop will be running the third time the execution is paused at line number 27, therefore, hitting the breakpoint. Run the application and wait for the breakpoint to get hit.



Notice that the condition information is live. It shows me the current Hit Count. The application stopped at debugging point when the hit count was 3. At this point the count can also be changed, let’s change it to 4, or it could simply be reset, and data tooltips can still be used to view the variables. If we hover over the products list we can see it already has two products (prod) in it, so we must be in the third iteration of the loop because we're breaking before we're adding to the list.



One of the interesting features w.r.t. Visual Studio 2015 breakpoint configuration is that if a breakpoint is accidentally deleted , it could again be applied by using Ctrl+Z.

A breakpoint condition with the Hit Count can be used anytime if we need to hit the breakpoint at specific hit count or at some particular interval of hits. This is normally useful while processing lists of items and in recursive methods. Even though the application is still running, another condition can also be selected to be added, let's add it to the conditional expression. We’ll check this by adding a Conditional Expression here. Let’s say we want the breakpoint to be hit when the product code of prod instance is “0004” . So click on Add condition option while the application is stopped at the breakpoint and add a conditional expression.



You can add multiple conditions and configure your breakpoint for desired debugging to improve productivity. When Add condition option is clicked a new row is added with all available options as shown earlier while applying Hit Count breakpoint. Choose conditional expression option and validate it to be true when prod.ProductCode==”0004”. Notice that you can write any expression in the expression text box. The expression could be simple or complex with multiple && and || conditions too. Moreover, while typing, the IntelliSense also works and helps to create expressions.



If you want you can delete the prior condition of hit count , else the debug point will be hit multiple times. I am removing the prior condition here. Run the application and you’ll see that the breakpoint is hit when the condition that was mentioned at breakpoint becomes true.



We see here the execution stops as soon as the condition of product code being “0004” is met.

Actions

Let us see how Actions work. By default, when the conditions are true, the debugger will pause at the particular breakpoint. This behaviour can also be configured by checking the actions. One can select to log the message, enter the desired message in the Message field provided.



We can also enter desired plain text of our choice and customise the message for better readability and understanding. Dollar ($) can be used to display system values here, when you type dollar in the message field , you get the list of all the pseudo-variables that can be used to log the message.



Curly braces {} are used to display the output or variables from the application or code base and you get the IntelliSense support as well in the message fields. You can log the message in the output window. let’s give it a try and try to log something at this breakpoint condition. You also have the option to Continue execution. This option refrains the debugger from pausing each time a breakpoint is hit.This option could be selected if you want to log the message without stopping at the breakpoint.



In actions message field, I am trying to log a message when the condition of prod having product code == “0004” is true. I have configured the message field to log $Function , $TID, $TNAME along with {prod} i.e. product instance and prod.ProductCode. notice that I have also used plain text like “Method : ”, “Product Instance”, “Product Code” to make my message more readable. I have chosen to continue the execution without stopping at the breakpoint. Let’s run the application and see what happens.



All the information that we defined in Message field is logged into output window as desired. All the details along with the plain text that I used is logged in the same sequence as defined. You can use the Log a message action anytime when you want to display information each time the breakpoint is hit.

New improved Error List

The new Error List in Visual Studio 2015 is now much more improved where you can get your live list of compiler and code analysis errors and warnings. The major improvements in the Error List include the display of the error code, linked to a document on that issue. You can click that link to view the document online. Filtering has been expanded much more. One can still filter on the current project or document, but now filtering can also be done on error severity, the error code, a set of projects or on a set of files.



The maximum error limit in Visual Studio 2015 has also been removed. Earlier there was no way to really tell how many errors we had in one go when the error number was too high. Each time we fix certain numbers of errors, we were shown more errors on compilation Now, all of your errors and warnings will appear in the Error List in one go.Let’s practically try to see the error list improvements. I have intentionally made few changes in the Main method of the program.cs class to get some errors and warnings. I have removed var from products declaration, added an empty catch block with an empty finally block. Before compiling the code, I have also enabled the Enable Code Analysis on Build option. You can find this option by right-clicking on your project, open properties and in properties window selects Code Analysis option , normally appears at last as shown in the image.



Now when we compile that code we get few errors and warning as expected.



We see here that we get errors and warnings from the compiler and as well from the code analyser. CS as a prefix to the error/warning code represents that it is through compiler and CC represents code analysers here. We got all the expected warnings and errors. Notice that errors and warnings have their respective symbols. The tabs at the top show 2 Errors, 5 Warnings and 1 Message. You can choose these options to filter and see what you need. Let’s say you don’t want to see Warnings and Messages, then you can click on the respective tabs above to see only Error list. Notice that every error code is in the form of a link when you click on any error code, it redirects you to its documentation page.Let’s click on CS 0103 i.e. the first error saying “The name ‘products’ does not exist in the current context”.



We see that the ink has redirected to MSDN link having the detailed document of that error.

Filtering has been expanded more to filter on errors, warning and severity as well. To check that just click on top of the columns of error list where the error/warning symbol is displayed.



As soon as you click on the top as shown in the above image, the filter option will appear there itself and you can click that filter icon to see the types of more available filters.



You can choose to filter the list based on your selection by checking or unchecking the check box. Filter option is widely available for code as well as for Projects. You can particularly select which code to include as shown below in the image,



Or which project or files to select as a filter.



So you can see that filtering option has been expanded to take care of multiple options, therefore, improving control, configurations and productivity of a developer.

Conclusion

In this article, we covered the new improved debugging techniques that Visual Studio 2015 has come up with. We covered the break point configurations with several practical scenarios and sneak peeked at a new improved Error list. These options can also be found in prior versions of Visual Studio, but VS 2015 has an improved and more discoverable version of them. In the next article, we’ll cover the remaining two debugging options that are PerfTips and new diagnostic tool window.