Diagnostic Tools debugger window in Visual Studio 2015

What are Diagnostic Tools?

First let’s define what we mean when we say “Diagnostic Tools” in Visual Studio. Diagnostic tools means different things to different people, and some would consider the debugger itself to be a diagnostic tool. In this context, when we say Diagnostic Tools, we mean tools that allow you to see historical information (data collected over time), as opposed to just a single moment in time (like when you are stopped at a live breakpoint). By that definition, there are three main examples of diagnostic tools that were available previously in Visual Studio 2013:

The Output window: allows you to see program output and other debugger events while it is running
IntelliTrace: allows you to see interesting events in your application and set the debugger back in time so that you can look at historical data in the Call Stack, and Locals windows. You can also see the list of every method call and its parameters (even when that method is no longer on any call stack).
The Performance and Diagnostics hub: allows you to perform a comprehensive performance analysis of your app as it runs without the debugger. You have your choice of performance tools to use, such as the CPU Usage tool and the Memory Usage tool, depending on the nature of the performance issue.
As you will see, we have taken all of these diagnostic tools and brought them closer together into a unified window. This new experience offers you two benefits:

The ability to monitor performance while debugging, and correlate performance data with debugging activity, and
A much richer and more useful experience for IntelliTrace and the Output window, dramatically shortening the time it takes you to diagnose an issue or verify a fix.

View original

Advertisements

How IEnumeberable might get you in trouble

Quite often I see a bug where a certain Factory method creates an IEnumeberable of objects.

While initially looking at the code you might not notice it, but that sort of code might lead to excessive creation of instances because of multiple enumeration of objects causing the factory method to create more objects that you expect.

For example let examine this bit of innocent looking code:
Continue reading “How IEnumeberable might get you in trouble”

Using .NET Reference Source for debugging

Improvements when debugging .NET Reference Source

Historically since the inception of this effort, Microsoft have published sources and PDBs for every major .NET framework update namely .NET framework 4.0 and 4.5. However these builds would be rendered effectively useless the moment any update to the framework was released, since the binaries on the updated box no longer matched the PDBs that were indexed on the reference source server. Unfortunately the design of the system that they had in place was geared towards doing single and infrequent pushes of sources and symbols out and did not account for the sheer volume of builds and patches that come are produced out of the .NET framework build system.

Continue reading “Using .NET Reference Source for debugging”

Blog at WordPress.com.

Up ↑