Three things from Eclipse that would be nice to have in Visual Studio to develop extensions

While I have been working with Visual Studio .NET since the first version (2002), some years ago I started a start-up with a friend to develop crossword games for J2ME-enabled mobile phones. So I learned Java, downloaded the Eclipse IDE and the EclipseME plug-in (now Mobile Tools for Java) to develop J2ME MIDLets, and I had a lot of fun 🙂

There are three things from Eclipse that impressed me from the start that all these years developing add-ins for Visual Studio I miss a lot:

1) There is no setup.

You download a zip file, unzip it to some folder and that is all. Compare this with the installation of Visual Studio that even for service packs is increasingly longer. This is also true for other Microsoft products like Office, but at least Office will “fix” the problem when the Web-enabled version appears, so you will be able to create documents or spreadsheets like you can do it today with Google Docs. If you develop extensions for Visual Studio you need to have several versions and even service packs installed on your machine, and installing all them is painful, and you can’t have a version without service pack and other with service pack on separate folders, and you can’t install CTPs or betas because nobody could cleanup and restore everything when uninstalled, and the “solution” to all this is to use… virtual machines, which have their own dosis of problems (at least Virtual PC), they are increasingly heavier, require more memory on your computer and you need some more steps to deactivate CTP timebombs. Imagine that you could unzip Visual Studio versions, service packs or CTPs/betas on separate folders of your machine without touching the Windows registry…

2) You can have the source code for the IDE.

I can not emphasize enough how important is this when you develop some non-trivial extension for Visual Studio. But until recently even the source code of the .NET Framework was not available, so tools like .NET Reflector to decompile assemblies appeared, a tool that would have made rich its author if he would have charged just five dollars to each .NET developer that uses it rather than making it freeware (thanks, Lutz). Microsoft provided the source code of the .NET Framework with the release of Visual Studio 2008, and even the mechanism to debug it if you need to do so. But the source code of Visual Studio remains closed so you can’t understand how some internals of VS work, not to mention debug it, why your add-in or package doesn’t load or give you a cryptic COM error, etc. While it is understandable that some portions should remain closed (such as the .NET compilers or parsers), others could be perfectly provided with source code. All new additions to VS are now managed (not native), so you can decompile them to try to understand how they work. It would be nice to have the source code without decompilation and be able to debug your extension along with Visual Studio code.

3) It was thought with extensibility in mind from scratch

I have not used extensibility in Eclipse but from what I have read, it was fully extensible from scratch and everything was made with a minimal shell with lots of plug-ins for the features. Visual Studio, on the other hand, only provided extensibility through add-ins, macros and templates in the initial VS.NET 2002. The VSIP program to develop 3rd party packages didn’t appear until the VS.NET 2003 release. You didn’t have something named Visual Studio SDK until the VS 2005 release. Something like the Visual Studio Shell didn’t appear until the VS 2008 release. All that complicated by an IDE that was born as a native, COM (not .NET) application to develop mainly .NET applications but that required extensions to be COM. We are still suffering that…

The good news is that Microsoft is working a lot and really hard on point #3 to catch up. I wish they can think about points #1 and #2 too.