15 features I love in Visual Studio 2015 – part 3 Debugging features

In this 3rd and final post it is time for the debugger features, yay!!!.  You might want to check out my 5 favorite editor and IDE features too.

Debugging multi-statement lines with the autos window

We have probably all debugged code like this, wanted to know what Helpers.DegreesToDirection returned and ended up re-writing the code temporarily to var dir = Helpers.DegreesToDirection…

As it turns out, this is completely unnecessary thanks to a feature that was introduced in Visual Studio 2013 but that few people know about. 

If you step over the line with F10, and open the autos window, you will find that VS has already done the return split for you.  Neat right?

Live Visual Tree – or F12 tools for XAML

Working with XAML for the past 3 years, I have been extremely jealous of the F12 tools for the web where one could simply press F12 in the browser and test and change styles and see the results live. And of course find out why an element rendered like it did.

Those tools have now arrived for XAML, in the form of

1. A Live Visual Tree that shows you all the XAML objects in the current visual tree, and lets you pick a XAML object from the tree, or pick a XAML object by selecting it in the app.

2. A Live Property Explorer that lets you change the properties and styles of the XAML elements while the app is running.

 

Read more about it on the Visual Studio blog

PerfTips

PerfTips is one of those, why didn’t anyone think of this before???

When you break, while debugging, you will see the perftip at the end of the line you stopped at.  The perftip tells you how long time how much time elapsed since you were last stopped. In this case it took around 3 seconds (give or take some overhead time for debugging) to execute the lines since the last breakpoint.

 

This is an excellent way to find slow sections of your code without having to add your own stop watches and debug code.

Clicking on the perftip will show the diagnostic tools and filter by the last 3 seconds in this case, so I can narrow down the issue further.

For more information and a debugging scenario for perftips check out the VS Blog

Diagnostic Tools

The Diagnostic Tools is a set of tools that allow you to see historical data rather than just data from a single moment in time like typical application debugging.  Most of this already existed in Visual Studio 2013 as separate entities (Intellitrace, events in the output window, performance and diagnostics hub with CPU and Memory usage tools and profiling). 

In Visual Studio 2015 this is brought together in a fantastic Diagnostic Tools Window, it’s a little bit like WindDbg light but with a UI

You can read a longer walkthrough of all the tools here.  I am just going to pick out 2 of them real quick

Intellitrace or Historical debugging (only in the Enterprise version)

In this example you can see that a number of NullReferenceExceptions were thrown and caught.  You can see this both in the debugger and represented as red and gray diamonds in the event section up top.

The debugger didn’t stop since they were handled and the process continued normally since they were caught, but they could still be causing havoc with perf, or something else so it is still interesting to find out what happened.

If you click on one of the exceptions, it will take you to the location and time where the exception happened. There is a reason this used to be called time travel debugging…

Depending on how much data you allow the debugger to save (which of course affects perf.) it could also have the locals stored.

So now we know why this happened and since it happens so often it might warrant a re-write where we check for null instead of try/catch

Memory usage

The Memory usage tab has a pretty neat feature that allows you find the root cause of a memory issue by taking snapshots of the process and comparing them. 

Here, I have taken two snapshots (2nd one is taken after clicking a refresh button in my app 4 times).

I can see without even looking at the snapshots that memory has increased by 49kb (not a lot but still), and the number of objects has increased by 789.

I then click on the +789 to get a list of all the objects on the heap, sorted by increase in instance count.

Now I look for something I recognize and find that the number of ForecastItems has grown by 28, so 7 per refresh button click…

and selecting the ForecastItems I get a root path at the bottom of the screen showing me that the reason these stick around is because they are part of ForecastViewModel which in turn is part of an observable collection of IForecastViewModels in MainViewModel

Armed with that it was pretty easy to go back to the code and track down why we accumulated ForecastViewModels, and the reason was because I forgot to Clear the Forecasts collection when I loaded new forecasts.

Lambdas in immediate and watch windows

Digging through all the items in a collection (like the forecastResults) just to look at the value of Temp can be a real time-waster. So my last productivity tip in Visual Studio 2015 is use lambdas in the watch or the immediate window to grab just the bits you are interested in.

Note: since this is code that needs to run in the context of your method, you need to make sure that you have a using statement for Linq in your cs file to use this.

Bonus: New Breakpoint IDE

I think the new breakpoint IDE also deserves a mention even though I already picked my 15 fave features.

The new breakpoint window also uses the peek functionality so the breakpoint settings are made while you are still looking at the code rather than opening up another window. 

The functionality you have here with setting conditional breakpoints and logging data to the output window is nothing new. It has been there for ages but it is now much more accessible and easy to use which makes me very happy both as an avid debugger, and as a UX aficionado.

 

With that said, it is time for me to go back to my coffee, and vacation dreams. 

 

Tess