Wish List for the Visual Studio Editor and Debugger: Drawing Inspiration from Other IDEs

March 11, 2013


One of the benefits of using more than one development platform, more than one IDE, and more than one debugger is that you gain a better understanding of what your personal ideal development workflow looks like. It might well be the case that no single tool provides every feature you’re excited about, which is what I feel these days. Because Visual Studio is my long-time (since 1999) favorite IDE and debugger, here are some features from other tools I’d like to see integrated in Visual Studio.

Inspired by command-line debuggers, like WinDbg/GDB/DDD/DBX

Command-line debuggers tend to make automation much easier than their visual counterparts. Visual Studio 2010 used to offer VBA macros, which you could use for fairly sophisticated automation. For instance, you could have a breakpoint trigger a macro that would set another breakpoint, dump out all thread stacks, look for local variable values, and evaluate complex expressions. In Visual Studio 2012, macro support has been removed from the IDE, which makes command-line tools even more powerful in comparison.

Here are some of the things you can do in command-line debuggers that you can’t do in Visual Studio today:

  • Set a breakpoint when a large memory location is read/written.
    This is something you can do in WinDbg using the !vprotect extension command to configure a PAGE_GUARD page, and then process the exception Windows will raise when the memory is accessed.
  • Run an arbitrary debugger command when a breakpoint is hit.
    In WinDbg, any breakpoint you set (including data breakpoints) can run any debugger command — and decide whether to actually stop execution or continue as if the breakpoint wasn’t hit.
  • Execute a set of debugger commands from a script file (the aptly named $$>< command in WinDbg).
  • Inspect managed heap contents, possibly running a command for each interesting heap object you encountered.
    This is very useful for managed memory leak diagnostics. For example, you could run the !gcroot command for all objects of a specific type:
    .foreach (obj {!dumpheap -type MyNamespace.MyClass -short}) {!gcroot obj; .echo —–;}
  • Load debugger extensions (like SOS or SOSEX) and extend your debugger with arbitrary commands. For example, SOSEX has a great variety of stack listing, object inspection, and synchronization-related commands that you could then use.

Inspired by Xcode

The Xcode IDE has a mixed reception from developers. I think most people moving to Xcode from Visual Studio will find it inadequate, but it actually has a few very nice features both in development-time and during debugging. This is not to say that I would actually want to do most of my development in Xcode — but I’ve already been spoiled by Visual Studio ๐Ÿ™‚

One thing Xcode is really good at is static code analysis, which it performs on the fly. Now, Visual C++ also has static code analysis (the /analyze compiler switch), but it only runs when you compile your project, and takes quite a while to produce errors. Also, there’s a big problem with signal to noise ratio, which I wish were addressed in future releases of the compiler. Here are a couple of examples:

  • Detecting a null pointer dereference and explaining where it’s coming from. (This is actually something Visual C++ can do, but with less explanatory details.)


  • Detecting reference counting errors.


  • Detecting errors that result from calling methods on a nil pointer, that would return garbage in the case of structs.


Another thing the Xcode debugger is pretty good at (thanks to the underlying lldb debugger engine) is smart breakpoints, and performing a variety of actions when a breakpoint is hit. The Apple version of macros is AppleScript, and Xcode breakpoints can run an arbitrary AppleScript script as well as any lldb command.

For example, you could configure a breakpoint so that it takes a screenshot of your iPhone Simulator whenever it’s hit, using the following AppleScript script [source]:

tell application "iPhone Simulator"
end tell

tell application "System Events"
       tell process "iOS Simulator"
               tell menu bar 1
                       tell menu bar item "iOS Simulator"
                               tell menu "iOS Simulator"
                                       click menu item "Hide Others"
                               end tell
                       end tell
               end tell
       end tell
end tell

do shell script "screencapture -m /tmp/screencapture.png"

Inspired by Eclipse

Although Eclipse draws lots of criticism — it’s slow, buggy, and some say ugly — it has an unparalleled set of built-in refactorings and code-fixes that make most other IDEs pale in comparison.

First, just take a look at the Refactor menu in Eclipse:


Now, many of these things can be added to Visual Studio through ReSharper or CodeRush or similar tools, but it’s actually very nice to have these features in the out-of-the-box IDE experience. Also, the code completion and error-fixing offered by Eclipse is so powerful that some people say you can create a new project in Eclipse, and just by using Ctrl+Space generate the entire source code for Eclipse itself ๐Ÿ˜‰

For example, here’s Eclipse offering to fix a problem where an anonymous class method is trying to access a non-final local variable from the enclosing scope:



I often suffer every minute I have to spend outside of Visual Studio. The shortcut muscle memory, the powerful code editor, and of course my favorite language — C# — make it somewhat a pain to use anything else. That is why I am constantly looking for more features to extend that experience — so that I can spend even more time in Visual Studio and be even more productive.

I am posting short links and updates on Twitter as well as on this blog. You can follow me: @goldshtn

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



  1. Andrew Hall - MSFTMarch 11, 2013 ื‘ 4:44 PM

    Great post. I would like to point out that Visual Studio 2012 did add explanatory details for many of the C++ warnings including null pointer dereference mentioned above (http://blogs.msdn.com/b/codeanalysis/archive/2012/03/08/what-s-new-in-code-analysis-for-visual-studio-11.aspx)

  2. EBJuly 23, 2013 ื‘ 2:26 PM

    I really don’t know why you guys went off the deep and decided that you needed a new type of app/code system to develop the next generation of apps for Windows or what you call it… Metro.

    I believe we could have still used the old forms from VS 2010/12 (using VB, C#, C++) – but perhaps with a more polished look on the forms – with touch friendly controls like larger finger-friendly text box, timers, buttons, check boxes etc. This is the way Apple does it.

    I knew that something was terribly wrong with Metro when the basic fundamental and universal code in Visual Basic simply did not work in Visual Basic:

    Msgbox “Hello World.”

    I don’t like or even appreciate the new Metro programming style or design interface – even VB code does not work in VB Metro. More confusion only creates more confusion. I feel vindicated when most users really want to switch back to the regular Windows desktop as oppose to using the new Metro interface.

    I am not saying that Metro is bad. I would create Metro apps if they used regular VB. My code would be compatible and I could release over 300 apps in a few months. But to painstakingly rewrite new code for Metro isn’t worth it and so it’s not going to happen. Even Xcode uses the same type of Rapid Application Development interface for their apps as we use for regular VB. Metro is not RAD. Had you chosen to follow Apple’s lead, the Metro store would have far more apps than the App Store.

    Perhaps a way to solve this problem is to create a automated converter from RAD apps to Metro apps or allow us to use existing code to create Metro apps.