The Visual Studio Debugger has long been regarded to be one of the industries best debugger. The VS debugger’s ability to give developer’s insight into the running behavior and state of their .NET and native applications has been the foundation of what has made Visual Studio the IDE of choice for millions of developers around the world. Over the years, Visual Studio has seen many many features come and go into the product line, but the basic functionality of the debugger has been a constant. The ability to easily set breakpoints, step, view variables, and run have been at the heart of every developer’s workflow on the Microsoft platforms.
The debugger is a very interesting feature set in Visual Studio. It is one of those areas of the application where you can walk up to any VS developer and ask “Hey, do you know how to use the debugger?” They will undoubtedly look at you funny and say something like “Of course. What, is this a trick question?”
But how many developers actually know how to make the debugger do their bidding? How many know how to only use the debugger as a last resort, and when you do have to use it, maximize your time with it in order to get back to what you need to be doing, which is maximizing value for your end users? Turns out, the Visual Studio debugger gives you much more capability than simply the ability to set a breakpoint. The VS debugger has so many little features designed to make your life just a touch easier in many and different ways, most developers either haven’t discovered them, or they haven’t realized how those features can be applied in a way that maximizes their effectiveness.
There are many reasons for this, ranging from real discoverability issues with the features, to the lack of desire of the developer to reach for anything beyond the bare minimum feature sets. Regardless, I’d like to take the next few blog posts and examine some of these features. Features ranging from IntelliTrace, a marquee feature of the Visual Studio 2010 Ultimate product, to Trace Points.
There have been many articles, books, and blog posts written about the debugger, but it has been awhile since the topic has seen some fresh print. But as I said, since many of the features in the debugger have remained constant, much of the content out there is still quite relevant. I highly recommend checking out Jim Griesmer’s posts on the debugger, and of course, John Robbin’s debugging books are a must read. For the more advanced, I would highly recommend Mario Hewardt’s books ( this one and this one ). And of course, the MSDN documentation isn’t a bad place to start either, but for some reason most folks seem to forget or assume that the debugger isn’t documented! Go figure.
I don’t know how many posts will make up this series, but I do know that my intent is to provide you with more pragmatic information that you can use in your everyday. If I can help you save 10 minutes a day just by showing you some trick with the debugger, I’ve done my job!
Though I have a pretty good idea of the topics I’d like to cover, if you have a topic related to debugging inside Visual Studio that you are very interested in, please give me a shout either via the comments on this post, or via direct email.