I’m sure this is a question that every developer of extensions for Visual Studio, whether add-ins or packages, wonders from time to time. If you develop extensions for in-house use, you can drive, incentivate or even force your organization to migrate to the latest version of Visual Studio. But if you develop extensions commercially, things are quite different.
At the time of this writing we have the following Visual Studio versions:
- Visual Studio .NET 2002, released in February 2002.
- Visual Studio .NET 2003, released in April 2003.
- Visual Studio 2005, released in October 2005.
- Visual Studio 2008, released in November 2007.
- Visual Studio 2010, to be released at the end of 2009 or in 2010.
Five releases start to be a lot of releases… even if you have managed to have a single code base for your extension (with some conditional compilation), or maybe even the same binary for several Visual Studio versions (with some dynamic adaptation to the Visual Studio version hosting the extension), and maybe the same setup, nothing can avoid you a lot of testing, to ensure that your extension works correctly on each Visual Studio version, because from time to time Microsoft introduces unintentionally new bugs. Furthermore, you would like to use new features of the .NET Framework like Generics of .NET 2.0, which you can’t use if your codebase is still to be build against .NET 1.0 or 1.1. You are also tired of having four whole releases of Visual Studio installed on your machine with identical shortcuts in the quick launch toolbar of your Windows (sort of Visual Studio 2008, which introduced the version number “9” in the icon). And some of the Visual Studio releases are not supported on your Windows Vista but since you want the latest OS, you don’t want to go back to Windows XP, so you install them anyway, and they work for the most part, but some very used features like Find hangs and you get frustrated…
So, you really wonder if you could drop support for VS.NET 2002. If your extension is a package, VS.NET 2002 didn’t provide support for 3rd party packages so there is no question. If your extension is an add-in, then you could probably drop support because VS.NET 2002 was the version 1.0 of the new IDE and it was somewhat incomplete and lacking some features that Microsoft took only one year to replace it instead of the usual two years cycle. And by the time people learned .NET and decided whether to use it for some serious project or not, VS.NET 2003 was out.
What about VS.NET 2003? This version introduced the Visual Studio Industry Program (VSIP) for packages, which in VS 2005 would evolve into the Visual Studio SDK. So, you really would like to get rid of VSIP and use only the new VS SDK, and dropping support for this version would mean that you can move your codebase to .NET 2.0, and your add-in can get rid of COM using toolwindows without a shim control, using XML-based registration rather than Registry-based registration, managed satellite DLLs instead of native C++ satellite DLLs, etc. And you wonder, how many people is still using VS.NET 2003? Hey, that’s stuff of five years ago! Could I get some usage statistics from somewhere, Microsoft perhaps? Do I send an e-mail to my customers? Do I drop support anyway?
Well, if you are a successful commercial vendor, you already know that all is about the customer, not about you, your technology, your preferences or your desires (if you are still a geek with disdain for marketing and sales there is good stuff to learn out there). So, let’s talk about the customer:
- Customers hate when they have some software and hardware that at some point is not supported by the vendor, no matter how old. I remember that I had an HP CD recorder that when Microsoft shipped Windows XP was no longer supported. I found an article from Microsoft pointing to the HP web site, and indeed HP stated that they wouldn’t provide Windows XP drivers for that model. My CD recorder could be old and slow (4x, I think) but at that time it worked for my needs and if I needed to buy a new one to work with Windows XP, I may well purchase it from another vendor…. I haven’t purchased an HP product since then for that reason.
- While you as a developer may have a MSDN subscription to get all the Microsoft software for development, many customers don’t. They buy some Visual Studio version and don’t upgrade unless they have the money and some compelling reason to do it (and maybe WPF, AJAX, etc, don’t qualify as a compelling reason). Think that the MSDN subscription is per-developer, not for a whole team. So only medium or big companies with special agreements (“Enterprise”, “Open”, “Select”) with Microsoft get new software as it is released. Students and hobbyists also get the latest versions in the form of Express editions, but these don’t support extensions, and you wouldn’t get much money from them anyway.
- Even if a company has a software subscription with Microsoft and receives the new Visual Studio versions, they may have dozens or maybe more than a hundred .NET projects. And they have better (business) things to do than to migrate them just for technology purposes, forced by a vendor. Their company has already installed some .NET Framework version, and their projects and the Visual Studio version that they are using meet their needs. Or they use the latest Visual Studio version for new projects, but they don’t migrate the old ones because it takes time to do it.
So, despite your big desires of getting rid of old Visual Studio versions, as a developer of add-ons you need to support many previous versions of Visual Studio, and for many years. It’s the price you have to pay for developing extensions and not standalone applications. If I had doubts about dropping VS.NET 2003 support for my MZ-Tools add-in, the last two support e-mails that I have received about my MZ-Tools 6.0 for VS.NET add-in were from people still using VS.NET 2003… and you would be really surprised of how many people still download the version of my MZ-Tools 3.0 version of my add-in for Visual Basic 5.0 each month despite I would think that everybody had migrated to Visual Basic 6.0…