Visual Studio 2010 extensibility moving beyond add-ins and packages…?

Last Thursday October 23 the VSX Team blog announced a VSX Talk at the upcoming PDC that contained this very interesting news:

“The next version of Visual Studio moves beyond add-ins and packages to unleash powerful new ways to customize and extend the environment. Learn about the Visual Studio extension model-built on a common Microsoft .NET extensibility framework–that makes it easy to customize Visual Studio in new ways. See how to create extensions for the new code editor and project system, and hear how to build your own graphical designers and specialized development environments.”

That the automation model (EnvDTE) for add-ins (and macros) was being somewhat de-emphasized was quite obvious in the last Visual Studio 2008 release, where after the great improvements that we saw in the VS 2005 automation model (EnvDTE80) very few was added in the VS 2008 version, and all the work of the VSX Team seemed to be about the Visual Studio SDK. But that there is something in the works to move beyond packages is something entirely new. The Visual Studio extensibility is hindered severely from the begining (2002 version) by the fact that the IDE is a native COM application, not a .NET application (some portions are .NET but the core is COM) and the attempts to hide this fact in the Visual Studio SDK have not been 100% successful. So, it is going to be tremendously interesting if the “Visual Studio extension model-built on a common Microsoft .NET extensibility framework” will solve this problem. I hope so very much.

Anyway, for existing Visual Studio extenders this doesn’t mean that you can forget about add-ins or packages because your product needs to support old versions of Visual Studio. I am still supporting VS.NET 2002/2003 in my MZ-Tools add-in and while I will stop supporting those versions at some point in the future, most vendors will have to support the VS 2005, VS 2008 and VS 2010 in the next few years so leveraging the same existing code base (whether it is an add-in or a package) will be common approach in most cases. But at some point in 4-6 years, when you need to support only from VS 2010 onwards, and when this new extensibility approach is more mature, maybe we can forget that VS is COM-based and automation will be truly simple. The first answers in a week, at the PDC…