Visual Studio is the number one development environment for Microsoft technologies and that is especially true for .NET based applications. When developing an application – building it on top of frameworks like ASP.NET, ASP.NET MVC, WPF or SharePoint – it is always great to have the ability to debug through your code in order to find out what is actually going on at runtime.ASP.NET Page Lifecycle methods for instance that are called in the different stages of page processing are a good example where debugging definitely helps you to understand which methods of your page are called in while ASP.NET processes the page request.
Limitations of debugging
There are however limitations with debugging that makes it a bit hard to analyze the exact workflow of an application when based on complex frameworks and optionally calling out to other (local or remote) components:
- While debugging, you only see the current stack trace but you don’t see the complete transaction trace including ALL different execution paths
- You can normally only debug through your own code. Its hard to figure out what is going on in the frameworks or libraries that are used
- Calling external (local or remote) services are treated like a blackbox – unless you have the chance to install a remote debugger and as long as the remote technology can be handled by Visual Studio (Native C++, .NET)
- Debugging changes the runtime behavior of your application and may even influence the execution paths, e.g.: running into timeouts, …
Last week at the PDC2008 in Los Angeles – Microsoft gave a preview of Visual Studio 2010 and a new feature that they call Historical Debugging. This feature will adress the first bullet item on my list but we still need to wait till the next release of Visual Studio – and – what about the other 3 points?
Transactional Tracing with dynaTrace
dynaTrace offers transactional tracing with its unique PurePath technology. It allows tracing every single transaction from where it enters your application, e.g.: ASP.NET Page Handler through all relevant methods that are executed within the same transaction context and is even able to trace the transaction across runtime and technology (Java and .NET) boundaries. Along the PurePath information like execution times, method arguments, exceptions, logging messages and database statements are captured.
How to integrate transactional tracing with Visual Studio?
As a developer I want to be able to launch my application as I am used to – from within Visual Studio by hitting Ctrl+F5 to run the app or F5 to debug it. In order to extend this capability with transactional tracing for my app I created a Visual Studio Add-In that launches the active project of the open solution with dynaTrace support. Binding the new command to the shortcut Ctrl-Shift-D now allows me to get transactional tracing support from within Visual Studio with a simple keystroke.
Transactional tracing now allows me to really see what is going on within my application. I can explore the PurePath to analyze how the ASP.NET Page is actually executed:
It also allows me to look at the captured data from different perspectives, like looking at all database statements that have been executed in context of a single transaction:
Or even follow a call to an external service and see what was executed within that service – no matter whether it is implemented in .NET or Java:
The ability to do transactional tracing triggered from within the development environment enables developers to better understand what is going on in their code, in the frameworks that they base their app on and in the services that their code relies on. Visual Studio offers these extension mechnisms and dynaTrace – with the PurePath technology – enables capturing the necessary data.