Over a million developers have joined DZone.

Diving Into Visual Studio 2015, Day 5: Debugging Improvements (Part 1)

DZone's Guide to

Diving Into Visual Studio 2015, Day 5: Debugging Improvements (Part 1)

In this section of the series on learning Visual Studio 2015, we’ll cover debugging improvements. We'll go over break point configurations with several practical scenarios and take a sneak-peek into the new improved Error list.

· Web Dev Zone
Free Resource

Make the transition to Node.js if you are a Java, PHP, Rails or .NET developer with these resources to help jumpstart your Node.js knowledge plus pick up some development tips.  Brought to you in partnership with IBM.

Visual Studio has always been a great IDE for code debugging. It provides numerous features for debugging and configuring the code. Being developers, we always spend a lot of time in running and debugging code, therefore, improvements to debugging features can have a big impact on our productivity. This article covers the debugging improvements that Visual Studio 2015 has come up with. The following are a few of the major features that will be covered in this article:

  • Breakpoint configuration improvements
  • New improved Error List
  • Tool window support for LINQ and lambda expressions
  • New PerfTips displaying execution time in the code editor
  • New Diagnostic Tools window

Breakpoint Configuration Improvements

The earlier versions of Visual Studio already provided the feature of breakpoint configuration, so it’s not new to developers. The only thing new in Visual Studio 2015 is the user experience and ease of using the configurations. Breakpoint configuration is now much easier to use and reachable.

Visual Studio 2015 introduces a new inline toolbar. With this toolbar, you can easily open the Breakpoint Configuration Settings or enable/disable the breakpoint. Secondly, the Context menu for break point configurations in Visual Studio 2015 is simplified. The few options of the Context menu have been moved to the Breakpoint Configuration Settings window. The Settings window now comes in a peek window, so you can easily check and change the settings as there will be no modal window. The whole breakpoint configuration is now divided into two parts, Actions and Conditions.

Let's try to understand the topic in detail with a practical implementation. I am using Visual Studio 2015 enterprise edition for this article and have added a console application named VS2015ConsoleApplication in my Visual Studio. Let’s say we have a MyProduct class containing product as an entity specific basic operations like fetching the product, returning the list of products as shown below.

 1: using System;
 2: using System.Collections.Generic;
 3: using System.Linq;
 4: using System.Text;
 5: using System.Threading.Tasks;
 7: namespace VS2015ConsoleApplication
 8: {
 9:     public class MyProducts :IProducts
10:     {
11:         List<Product> _allProduct = new List<Product>();
12:         public MyProducts()
13:         {
14:             _allProduct.Add(new Product {ProductCode="0001",ProductName="IPhone",ProductPrice="60000",ProductType="Phone",ProductDescription="Apple IPhone" } );
15:             _allProduct.Add(new Product { ProductCode = "0002", ProductName = "Canvas", ProductPrice = "20000", ProductType = "Phone", ProductDescription = "Micromax phone" });
16:             _allProduct.Add(new Product { ProductCode = "0003", ProductName = "IPad", ProductPrice = "30000", ProductType = "Tab", ProductDescription = "Apple IPad" });
17:             _allProduct.Add(new Product { ProductCode = "0004", ProductName = "Nexus", ProductPrice = "30000", ProductType = "Phone", ProductDescription = "Google Phone" });
18:             _allProduct.Add(new Product { ProductCode = "0005", ProductName = "S6", ProductPrice = "40000", ProductType = "Phone", ProductDescription = "Samsung phone" });
20:         }
22:         /// <summary>
23:         /// FetchProduct having price greater that 3000
24:         /// </summary>
25:         /// <returns></returns>
26:         public List<Product> FetchProduct() => (from p in _allProduct where Convert.ToInt32(p.ProductPrice) > 30000 select p).ToList();
28:         /// <summary>
29:         /// FetchProduct
30:         /// </summary>
31:         /// <param name="pCode"></param>
32:         /// <returns></returns>
33:         public Product FetchProduct(string pCode)
34:         {
35:             return _allProduct.Find(p => p.ProductCode == pCode);
36:         }
38:         /// <summary>
39:         /// FetchProduct with productCode and productName
40:         /// </summary>
41:         /// <param name="productCode"></param>
42:         /// <param name="productName"></param>
43:         /// <returns></returns>
44:         public Product FetchProduct(string productCode, string productName)
45:         {
46:             return _allProduct.Find(p => p.ProductCode == productCode && p.ProductName==productName);
47:         }
49:         public List<Product> GetProductList()
50:         {
51:             return _allProduct;
52:         }
53:     }
54: }

Where IProducts is a simple interface:

 1: using System;
 2: using System.Collections.Generic;
 3: using System.Linq;
 4: using System.Text;
 5: using System.Threading.Tasks;
 7: namespace VS2015ConsoleApplication
 8: {
 9:     interface IProducts
10:     {
11:         Product FetchProduct(string productCode);
12:         Product FetchProduct(string productCode,string productName);
13:         List<Product> GetProductList();
14:     }
15: }

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.

 1: using System;
 2: using System.Collections.Generic;
 3: using System.Linq;
 4: using System.Text;
 5: using System.Threading.Tasks;
 7: namespace VS2015ConsoleApplication
 8: {
 9:     public class ProductCodeWithPrice
10:     {
11:         public string ProductCode { get; set; }
12:         public string ProductPrice { get; set; }
14:     }
15:     class Program
16:     {
17:         static void Main()
18:         {
19:             var myProducts = new MyProducts();
20:             var products = new List<ProductCodeWithPrice>();
21:             var allProducts = myProducts.GetProductList();
22:             foreach (var product in allProducts )
23:             {
24:                 ProductCodeWithPrice prod = new ProductCodeWithPrice();
25:                 prod.ProductCode = product.ProductCode;
26:                 prod.ProductPrice = product.ProductPrice;
27:                 products.Add(prod);
28:             }
29:             Console.ReadLine();
30:         }
31:     }
32: }

Now let's 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 the 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.


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 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, greater than/equal to, or equal to in order 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 three iterations. So we choose Hit Count option as condition and "Is equal" to option in 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 conditions information is live. It shows me the current Hit Count. The application stopped at debug 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 of Visual Studio's 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 added; let's add it through 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 the 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 textbox. 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.


Let us see how Actions work. By default, when the conditions are true, the debugger will pause at the particular breakpoint. This behavior 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 the desired plain text of our choice and customize 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 ability to display 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 a 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 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 the properties window, select Code Analysis option, normally appears at last as shown in the image.

Now, when we compile that code, we get a few errors and warnings, as expected.

We see here that we get errors and warnings from the compiler and the code analyzer. CS as a prefix to the error/warning code represents that it is through compiler and CC represents code analyzers here. We got all the expected warnings and errors. Notice that errors and warnings have their respective symbols. The tabs at the top shows 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 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 the filtering option has been expanded to take care of multiple options, therefore improving control, configurations, and productivity of a developer.


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 into the 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.

For more technical articles you can reach out to my personal blog, CodeTeddy.

Learn why developers are gravitating towards Node and its ability to retain and leverage the skills of JavaScript developers and the ability to deliver projects faster than other languages can.  Brought to you in partnership with IBM.

visual studio ,visual studio 2015

Published at DZone with permission of Akhil Mittal. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}