Easier Debugging with ReSharper and the Clipboard

We’ve all done it at one point or another. Our application throws an exception and we start wading through a standard Windows error dialog or a log file to examine the exception and stack trace. If you’re a ReSharper Jedi, you’ve probably copied the exception and stack trace to the clipboard and hit CTRL-SHIFT-E (IDEA) or CTRL-E, T (VS) in Visual Studio to launch ReSharper’s Stack Trace Explorer. (If you have’t, you’ll see the Stack Trace Explorer in just a second.)

Let me show you an easier way that works well on desktop or Silverlight apps. I’ll use Silverlight for demo purposes, but the same technique works with WPF and WinForms. First we need to hook up a global error handler:

public MainPage() {
    InitializeComponent();
    Application.Current.UnhandledException += HandleApplicationUnhandledException;
}

private static void HandleApplicationUnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e) {
    if(Debugger.IsAttached) {
        Clipboard.SetText(e.ExceptionObject.ToString());
    }
    e.Handled = false;
}

Please note that this is demo code and I’m simply hooking this up in the code behind. In a larger application, I would typically publish an ErrorOccurred message to my application’s message bus and register a listener that would contain the code in HandleApplicationUnhandledException.

Notice that I’m checking whether a debugger is attached. If so, I place the contents of the System.Exception (or derived exception) on the clipboard. (Clipboard is in the System.Windows namespace for Silverlight and WPF apps, but there is an identically-named class in System.Windows.Forms.) The reason that I’m checking whether a debugger is attached is so that end-users don’t get the clipboards spammed with exception text. You could conditionally compile the code so that production builds don’t contain it, but personally I like having the code in production too. It means that I can grab an old build, attach a debugger, and get the same exceptions that the end users are getting.

Now that the exception and stack trace is on the clipboard, I jump over to Visual Studio and press CTRL-SHIFT-E (IDEA) or CTRL-E, T (VS). I am immediately presented with ReSharper’s Stack Trace Explorer as ReSharper is smart enough to grab the current clipboard contents to display:

StackTraceExplorer

The advantage here is fictionless debugging as you no longer have to find, select, and copy the exception and stack trace to the clipboard. It’s there for you automatically. As soon as you hit an exception, simply jump to Visual Studio and press CTRL-SHIFT-E (IDEA) or CTRL-E, T (VS) and you’re ready to find the problem. Also note that all the method names in the ReSharper’s Stack Trace Explorer are hot links to the appropriate code file allowing for easy navigation of your code base, the .NET Framework, and third-party libraries.

One quick note regarding Silverlight… Many modern browsers (e.g. FF4, IE8+, Chrome, …) will run Silverlight in a separate process. So even when you launch with debugging (F5), you’ll be attached to the browser process itself and not the child process that is hosting Silverlight. To correct this, simply go to Debug… Attach to Process… and find the hosting process where the type is Silverlight. (For FireFox 4, the hosting process is called plugin-container.exe. For IE8+ and Chrome, the hosting process is called iexplore.exe or chrome.exe, respectively. Just look for the one hosting Silverlight as noted under the “Type” column.)

AttachToProcess

Happy Debugging!

About James Kovacs

James Kovacs is a Technical Evangelist for JetBrains. He is passionate in sharing his knowledge about OO, SOLID, TDD/BDD, testing, object-relational mapping, dependency injection, refactoring, continuous integration, and related techniques. He blogs on CodeBetter.com as well as his own blog, is a technical contributor for Pluralsight, writes articles for MSDN Magazine and CoDe Magazine, and is a frequent speaker at conferences and user groups. He is the creator of psake, a PowerShell-based build automation tool, intended to save developers from XML Hell. James is the Ruby Track Chair for DevTeach, one of Canada’s largest independent developer conferences. He received his Bachelors degree from the University of Toronto and his Masters degree from Harvard University.
This entry was posted in .NET. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Matt Hidinger

    Welp it finally happened, the buzzword prevalence took complete control over my subconscious.

    I read all the way through this article thinking the title was “Easier Debugging with ReSharper and the Cloud”

  • Anonymous

    @Chase – You can do the same thing with ASP.NET if you’re running in Cassini or IIS Express as the app is running in the same session and user account as Visual Studio. The major disadvantage is that you need a reference to System.Windows or System.Windows.Forms (for access to the clipboard) in your ASP.NET app, which I wouldn’t recommend. If you’re running full IIS under a different user account, you can’t use this technique at all as the clipboard that you’re copying to from ASP.NET is in a different session than the clipboard accessible by Visual Studio. In either case, if you’re running ASP.NET, I would simply dump the full exception out to the browser so that you can easily copy it. You can then use ASP.NET’s usual built-in mechanisms for handling custom exceptions (remoteOnly, on, off). Not as convenient, but safer IMHO.

  • http://twitter.com/ChaseFlorell Chase Florell

    what would it look like to do this with asp.net? Do I simply have to still “copy” the stack?

  • Pingback: Tweets that mention Easier Debugging with ReSharper and the Clipboard | James Kovacs -- Topsy.com