Visual Studio, you're doing it wrong 27 Feb 2012

If there's one thing I've come to learn about life, it's that most things are neither completely black nor completely white. There's an infinity of shade of grays in between. And if the announce of the Visual Studio (VS from now on) 11 beta taught me something, it is that VS 11 is exactly that. Neither completely black, nor completely white. But very gray. Oh so gray. I won't comment about the new look here, as the object of my ire with VS and its apparent roadmap lies at a completely different level. And boy am I annoyed to see where the VS team puts its focus. Do you remember Steve Yegge's rant about the need of a programmable platform at Google? It's a tad long (euphemism of the day), but it's well worth the read. And with Visual Studio, Microsoft is exactly failing at that. Visual Studio 11 will be the sixth iteration of Visual Studio with .net support. And for a .net programmer like myself, it's still a terrible platform to extend. I want to be able to have complete control over my environment by programming it. I'm a firm believer in meta-programming, I want to be able to program my IDE all around, automate tasks, manipulate my projects and my code, and complement the UI myself. Have you ever tried to write a plugin for Visual Studio? To keep on going with euphemisms, let say it's not a pleasant experience at all. It's quite a shame from the company that brought us the .net framework and C#. Most of the APIs to plug into VS are poorly documented COM wrappers from another age. VS 2010 introduced some managed APIs that are addressable from MEF, and they're actually pretty cool, but they only cover a small surface of what VS has to offer. And even those too are poorly documented, compared to the level of documentation for the .net framework. Roslyn is also going to somewhat improve things. But it's not planned for VS 11, and it's also restricted to a subset of what VS offers. If you want to interact with the project system for system, you can use the disgrace that the MPF (Managed Project Framework) is. It's a buggy piece of code that you have to dig from codeplex, with terrible documentation. If googling for documentation about it brought you to the MSDN, you can read that the types there are in:

Assembly: MPF.Project.NonShipping (in mpf.project.nonshipping.dll)

How friendly. And because no one really knows about all those obscure APIs, your only source of knowledge is the Microsoft VS extensibility forum. Which is also another source of frustration entirely : you have to wait for MS employees to help you out. For anyone who wrote eclipse plugins for instance, VS is a huge step back. No wonder the plugin ecosystem of eclipse is so flourishing, it has been designed to be pluggable. I think it is actually hurting VS itself, and as a consequence, the .net platform as a whole. I really think that the experience of the .net programmer would be quite different if from the beginning VS would have exposed a proper managed API, with the same quality and care that you can find for the .net framework. Or if at least, they would have seriously worked towards that during the years. Folks from Microsoft said they value feedback for betas. Here's one: invest in making Visual Studio a great platform for the .net programmer. Expose real managed APIs, let us plug into as much features as possible. .net programmers all around will take care of improving the experience of developing with Visual Studio much faster than what it takes you to add a better search into VS. Also, don't value feedback only during betas. Interacting with microsoft connect most of the time result in huge frustration. It's the only place where I, a customer, have been told that my bug won't be fixed because someone was scared of getting customer complaints.