You may have noticed that I am not blogging too much these weeks. The reason is that I have been working on the next version of MZ-Tools (and it is too early to comment about it) and testing the VS 2010 Super-Limited-CTPs that Microsoft provide to some people to test their extensions (add-ins, packages, etc.). These SLCTPs are under Non-Disclosure-Agreement (NDA) so the bug reports are private and I can’t comment what is fixed or it is still wrong. I am looking forward to the public VS 2010 Release Candidate to provide more information in the add-ins area.
On a separate thing, I have finished watching the videos of the Visual Studio Extensibility (VSX) Developer Conference October 2009 that were of my interest. I have updated the Resources page on my web site to list all the videos.
The first thing that strikes me is that none of the 20+ sessions is devoted to add-ins, and none was devoted in the 2008 conference too. Add-ins is an area of extensibility that is basically dead for Microsoft, only maintained due to the number of add-ins out there. While not as easy as they should be, historically add-ins have been the easiest way to extend Visual Studio, and originally in VS.NET 2002, the only way to do it providing a user interface (macros don’t provide user interface, the VS SDK was not introduced until VS 2005 and the former VSIP SDK was introduced in VS.NET 2003). The EnvDTE API is not certainly elegant and it suffers lots of inconsistencies and drawbacks that I have blogged about extensively all since I started this blog back in November 2006 (it turned 3 years recently), but it worked for most of us, specially because it was powerful enough for most purposes and the alternative (the SDK) was even worse until recently. If I had to start today building a VS extension, the SDK would be the way to go, but when you have an 8-years old add-in with tons of lines of code, it is difficult to think about migrating it knowing that it will provide no added value to the end users once migrated and tested completely.
The second thing that strikes me is that there are no progress in the extensibility of ASP.NET Webforms or the new WPF / Silverlight forms for add-ins (or may even for packages, I don’t know). If your extension wants to manipulate programmatically those forms or usercontrols, it’s going to be a difficult time. The Window.Object may return something for ASP.NET forms, but nothing for WPF / Silverlight forms. AFAIK, the designer of WPF is even a separate process and when they talk about WPF Designer Extensibility, they mean extensibility for developers of WPF controls to provide editors, adorners, custom actions or menus, etc. It seems that all emphasis about VS extensions is about to explore or manipulate code, and never to explore or manipulate forms/usercontrols.
The last striking thing, on the positive side, is that Visual Studio has got so much extensibility in several areas to deserve an annual conference with lots of sessions. That’s certainly great.