Driving the IDE tools forward

03 August 2006

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).


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.


7 comment(s)
Joe Brinkman
 I am glad to see this decision.  Quite honestly there are some standard refactorings that some of my old colleagues had with Eclipse that I definitely miss in CodeRush/Refactor.  The ability to push code up or down the inheritance chain immediately comes to mind, and the ability to do full project renames is another.  From my perspective dropping 2002 sounds like the right decision if it will buy us some of these missing refactorings.
3 August, 2006
I was having the same discossion yesterday on wether to switch now to VS2005 or to wait more. We actually use VS 2003.

One of our competitor develop a app similar to ours but ... in DOS and FoxPro. It's a great app with a lot of functionalities ... but it's now impossible for him to do an migration without a complete rewrite. As a result we take customers from him that just want to be "up to date", be able to use internet, use word and excel ... just use nowadays computer you see.

We reached the conclusion that if we want to keep the market in the next 10 years we have to stay "up to date". And so we will migrate to .Net 2.0 very soon.

All this to say that if you want to keep your market, you should just go ahead. Your competitors won't wait for you just because you want to wait for the people that still use VS 2002. And I don't want to use something else than CR and RF! At the moment you're way ahead of the competition, it's up to you to keep the lead for the years to come

Anyway, I guess the market is more promising for VS 2005 and Orcas than for VS 2002.

Just my 0.02$
4 August, 2006
Travis Illig
My vote is move forward and drop 2002.  I haven't even tested CR_Documentor with VS 2002 (though I assume it will work since you guys nicely abstract that away from me).  We use VS 2003 at work since our customers take their time when adopting new tech, but several of us are doing internal development with VS 2005.  I understand the issue with folks wanting to support legacy code (isn't it sad that .NET 1.0 stuff is "legacy code" now?), but the times are a-changin'.

Drop future support for 2002, but don't drop the download of the last version that does support 2002.  Leave it around and maybe provide bug fixes for a little while.  The 2002 folks won't get the very newest and coolest, but they won't necessarily be left out in the cold, either.
4 August, 2006
We're getting close to releasing version 6.2 of DXperience and the .NET component sets (if you're a DXperience...
4 August, 2006
Miha Markic
Go forward, of course.
5 August, 2006
Daniel Corbett
I agree with the others...     3.0 and Orcas are coming down the pipeline soon.   If you don't support those new features (and it clearly seems just from your post that MS has standardized on these new PIAs, and the features are likely only accessible through them), then you will be left behind!
5 August, 2006
Time again I think for you to take another look inside the CTO's brain to see what he's considering for...
17 August, 2006

Please login or register to post comments.