I have been developing add-ins for Visual Studio since the first Visual Studio .NET 2002 version. But, as you already know if you are long-time reader of my blog, add-ins have become now second-class citizens in the Visual Studio Extensibility (VSX) ecosystem, something that manifests in the following facts:
– Minor enhancements of the automation code model (EnvDTE*.*, EnvDTE80, VSLangProj*.* etc.). The last Visual Studio versions, while have shipped new assemblies EnvDTE90.dll, EnvDTE100.dll, etc., they have provided very little new functionality.
– The code model (EnvDTE.ProjectItem.FileCodeModel) has lacks and bugs (that I reported at Microsoft Connect) that are not going to be fixed.
– Add-ins can not use the VSIX deployment mechanism, nor the Visual Studio Gallery as packages can. They remain in a separate Add-In Manager, rather than the new Extension Manager.
– Add-ins suffer a lot when Microsoft decides to change some internal implementation (the VS 2010 release, which changed Office-based commandbars by WPF-based ones was specially painful, I had to report tons of bugs). The reason is Microsoft doesn’t use add-ins (only packages), so they are less tested, either manually or automated (CommandBar model, etc.).
– Several improvements that I have suggested have been rejected, to the point that I won’t bother to suggest anything more about add-ins.
Ultimately, it seems that Microsoft’s intention at some point is to remove add-ins, as they did with macros in VS 2012. That doesn’t mean that the automation model will be removed, because packages can use it too, but it means that the Add-in Manager and the way add-ins create commands and UI items will be removed.
So, I have decided to start moving to Visual Studio packages, although slowly. I have already completed the “theory” part reading the available information, and I will start practicing the next weeks and months, until I find the best approach to migrate a heavy add-in like MZ-Tools to a package. Rather than migrating right now as soon as possible, I want to explore a concept that I am thinking about a lot lately: the dependency inversion principle, which means to make a Visual Studio “plug-in” independent of Visual Studio dependencies, through the use of “adapters” and programming against interfaces. For example, the plug-in would use an invented ISolution interface, that would be implemented by a type that can use the automation model (EnvDTE.Solution) or the IVsSolution interface of Visual Studio, depending on the adapter that I use to connect it to Visual Studio. While more complex at first sight, that independence allows to host a plug-in in several Visual Studio versions, different hosts (Visual Studio and VBA editor, for example) and to use the same integration tests used in Visual Studio (real but slow) with stubs (fake but fast). I will share all this as it develops.