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.

2 thoughts on “Three things from Eclipse that would be nice to have in Visual Studio to develop extensions”

  1. 1) Installers were created because of novice users who would prefer running a standard setup.exe file, than to have to install an unzip tool (though Microsoft has now included an unzip tool by default in the newer versions of Windows), extract the files to a folder, and create shortcuts or start menu items for it.

    As for programs not requiring the registry, Windows programs used to do that too you know, back when every program stored their settings in *.ini files. The registry was created for a reason, and that too of the fact that it’s usage is now encouraged rather than ini files. (there are commercial programs still using ini(s) instead of registry too)

    2) Provide the source code for VS for free? That practically means they are giving away the IDE for free, which goes against their business decision to make VS a commercial product. Sure, Sun is doing exactly that for Java, but they are making up for their losses by charging exorbitant prices for the other things they do charge for, like their server hardware range and support options? It’s really just a difference in business tactics when it comes to the bottom line.

    3) As you’ve mentioned, Microsoft is working on this. Previously Microsoft tend to target enterprise users, but are now opening up to the ISV markets. Sun, on the other hand, has turned towards individual users much earlier on in an attempt to capture market share. As mentioned in point two, it’s really just market tactics either way, and competition will ensure they will meet some point down the line.

  2. just to add a few more daily life issues for coding as opposed to developping extensions…

    – code outline!
    – proper syntax highlighting
    – ctrl-click to jump to definition, or to switch between def and declaration
    – code completion that actually works
    – brace matching!!!! no kidding, it doesn’t work in vs2008 express in c++

    some things I miss in eclipse:
    – easiness of build and run, no toolchains and makefiles etc…
    – the vs debugger!

Comments are closed.