Driving the IDE tools forward

I was chatting to the IDE tools team the other day about where we were and where we want to go. CodeRush and Refactor! Pro 2.0 are amazing products that have been well-received but, as I was working on some C# code last night, there's still a long way to go for both of them. For instance, with Refactor! Pro we are only just starting to explore refactorings that affect multiple files (say a rename of a public class).

(By the way, if you haven't seen this video yet of the new stuff in Refactor! Pro 2.0, you might not know about the Rename public types option that's available as an "early experience" feature. Go to DevExpress | Options, select Editor\Refactoring\Rename, and then check the box and click OK. Now you are able to rename public types. Please let us know via the usual channels if you find any issues.)

So for example last night, I was working away using Visual Studio with CodeRush and Refactor! Pro, and I'd written some code like this:

    public void FlagDeleted(ListNode node) {
      NodeState newState;
      NodeState oldState;
      do {
        oldState = node.state;
        newState = new NodeState(true, oldState.Next);
      } while (!node.CasState(oldState, newState));
    }

as part of a LinkedList class when I realized that the code didn't have anything to do with the linked list, but, instead, had everything to do with a node (the one being passed in, in fact). The method should have been part of the ListNode class instead:

    public void FlagDeleted() {
      NodeState newState;
      NodeState oldState;
      do {
        oldState = state;
        newState = new NodeState(true, oldState.Next);
      } while (!CasState(oldState, newState));
    }

Fowler refers to this as Move Method.

Now the point of this is not to say, woo-hoo, I've discovered a refactoring we should have in Refactor! Pro (in fact, we already know we want to do this one, but it generally involves multiple file updates and we don't do those very well yet -- witness the early experience Rename functionality), but to show that there is still a long way to go and normal programming brings up examples like this quite quickly.

And that brings me to another point. Currently we support Visual Studio 2002, 2003, and 2005. When we began integrating the VSIP interfaces into DXCore (VSIP is Microsoft's COM API into Visual Studio), Microsoft’s primary interop assemblies (PIAs) weren't available. So, we translated the interfaces that we needed into C# and created our own interop assembly. Eventually, of course, Microsoft released their PIAs, but built them under .NET Framework 1.1. They are a mite temperamental to say the least when loaded in VS2002, so we essentially ignored them in DXCore.

Unfortunately, the release of VS2005 moved the goalposts. VS2005 introduced a lot more managed packages to access the new XML language service, the improved project system (much needed for multi-file refactorings), Team System stuff, SQL integration, etc. And they all use Microsoft's PIAs. So, if we stick to our interop assemblies we can support VS2002; if we switch to the official PIAs we can no longer support VS2002, but we get the benefits of much better integration with VS2005 and, a bit later, Orcas (and Orcas and .NET 3.0 are not that far away).

Umm.

In essence, to move forward, to be able to support more of the things we should be implementing (and want to implement), we have to strongly consider dropping support for VS2002. Now, I'm sure that the vast majority of our customers don't use VS2002 and have already moved to VS2003, and maybe even VS2005. VS2002 is getting long in the tooth and VS2003 was, frankly, a major improvement; similarly .NET Framework 1.1 and 2.0 have some great enhancements over .NET Framework 1.0.

So, I would like to give some warning that, although we'll be supporting VS2002 over the short term with minor upgrades, I think the next major version of the IDE tools is likely to only support VS2003 and VS2005.

Comments?

Free DevExpress Products – Get Your Copy Today