If you have read about and played with Visual Studio 2010 Beta 1, you will have notice that we are under a major change, not so breaking in the external shell but internally. Visual Studio was born as a native, COM-based, C++ application and it seems that it has started a journey of several years towards a managed, .NET application. For the end user, the changes are not so huge: a more nice look and feel in commandbars, toolwindows or editor windows, a new extension manager to discover and install extensions, etc. but for developers extending Visual Studio, although in the long term this will be great, in the short term this is kind of a nightmare because of:

• As it happens with new development, it will be plagued with bugs until all of them are fixed.
• Some things are being “deprecated”. Have you noticed the “DeprecatedException” when using properties of the new CommandBars, CommandBarButtons, etc?
• At the very least, you must test completely your extension (add-in, package) to see if it works with VS 2010, and either report bugs to MS or find workarounds to make it work.
• You need to think carefully whether or how to leverage new extensibility features of VS, or keep using a common denominator. That is, for end-users it is great all the new improvements in each VS iteration, but as a developer of commercial or public extensions, you need to target many versions of VS. For example: do you use an common extension with .NET 2.0 for VS 2005, 2008 and 2010? Or do you create a separate version for VS 2010, maybe with .NET 4.0? Do you use the same setup for all? Or do you leverage the new Extension Manager for VS 2010?
• Since add-ins are starting to be second-class citizens (with few development of new classes, methods and properties in EnvDTE* assemblies and missing or contradicting information about support in the new Extension Manager), do I start migrating to a package? Is it sensible to do it now when VS.NET 2003 should be still supported? Do I wait some years when package development (SDK) is truly easy?