Introduction
Visual Studio has always been a great IDE for code debugging. It provides a numerous features for debugging and configuring the code. Being a developer we always spend a lot of time spend time in running and debugging the 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
Learning Visual Studio 2015 Series
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 more 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 us 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;
6:
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" });
19:
20: }
21:
22: 23: 24: 25: 26: public List<Product> FetchProduct() => (from p in _allProduct where Convert.ToInt32(p.ProductPrice) > 30000 select p).ToList();
27:
28: 29: 30: 31: 32: 33: public Product FetchProduct(string pCode)
34: {
35: return _allProduct.Find(p => p.ProductCode == pCode);
36: }
37:
38: 39: 40: 41: 42: 43: 44: public Product FetchProduct(string productCode, string productName)
45: {
46: return _allProduct.Find(p => p.ProductCode == productCode && p.ProductName==productName);
47: }
48:
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;
6:
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;
6:
7: namespace VS2015ConsoleApplication
8: {
9: public class ProductCodeWithPrice
10: {
11: public string ProductCode { get; set; }
12: public string ProductPrice { get; set; }
13:
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 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 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 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 feature w.r.t. Visual Studio 2015 break point 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 any time 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 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 break point 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 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 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 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 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 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 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 properties window select 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 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 un checking 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 in 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.
