Visual Studio Ceases Support of Add-Ins in Community Previews 14

Aug 05 2014

Author: Paul Eremeev

Not so long ago, Microsoft showed the next version of Visual Studio presently known as Visual Studio 14 CTP (Community Technology Preview). After I installed the latest CTP version available, one of the things to catch my eye right away was the absence of the Add-In Manager item in the Tools menu. A year has passed since the time when add-ins were declared as deprecated in Visual Studio 2013, and it seems now the new IDE version will completely cease their support.

I should explain to those not familiar with the nuances of plugin development for Visual Studio that by add-ins in this context we mean a certain type of Visual Studio extension modules (or simply plugins). This plugin type was introduced to Visual Studio quite a long time ago. Since then, other methods of extending Visual Studio's standard functionality have been developed, both complementing add-ins's functionality and duplicating it but in a way more convenient for developers and end users (MPF, VSPackage, MEF). We won't focus on these details now; let me only recommend you our series of articles on the topic of Visual Studio extensions in case you want to find out more about it.

The PVS-Studio product, besides the C++ analyzer itself, includes plugins to allow it to integrate into a number of different IDEs – first of all, naturally, Visual Studio. Once, in the times of the earliest PVS-Studio versions, we utilized add-ins to integrate the tool into Visual Studio. But we upgraded all our projects to the VSPackage plugin format quite a while ago.

Sure, those Visual Studio plugin developers who still use add-in format to integrate with the IDE (strange as it may sound, such plugins still do exist and are even actively developed) will soon be forced to upgrade their projects to a more up-to-date format. However, what personally I am wondering about is if cancelling all support for add-ins, as planned by Microsoft, will cause any troubles to us, i.e. those who use the VSPackage format in their products.

It may seem at first that no troubles should occur. Microsoft will hardly drop support for VSPackage in the foreseeable future – if only because a great deal of the regular Visual Studio components are implemented in this very format. However, the comment on the news we are discussing by Carlos Quintero (MVP, specializing in Microsoft Extensibility) made me wonder and take a look at this problem from a bit different angle.

In particular, before our plugin can launch static analysis of project files, it needs to collect all the information about these files concerning their build specifics – compilation arguments, project configuration parameters, and so on. To do this, the plugin uses the interfaces of the EnvDTE object, the top-level interface of the Visual Studio automation model. However, it is to support macros and add-ins that the Visual Studio automation model was initially created for, and the model was introduced as early as in the first Visual Studio.NET 2002 version, while VSPackage was developed somewhat later. However, macro support was ceased in Visual Studio 2012, add-in support will most likely be cancelled starting with the next version... what next? Won't Microsoft decide "one fine day" to completely give up EnvDTE too, especially taking into account that more and more Visual Studio components are using WPF, MEF, MPF interfaces (i.e. that very Package interface describing VSPackage plugin), and IDE services? EnvDTE, in its turn, may become (or perhaps has already become) an obsolete intermediate layer left solely for the sake of compatibility.

Well, we haven't seriously considered abandoning EnvDTE interfaces yet. Personally I, for instance, cannot imagine for now a more convenient (or at least as convenient) way to parse the project tree, get the list of all the necessary files and their build parameters, without such interfaces as VCProject and ProjectItem. Moreover, PVS-Studio in particular has to keep supporting old Visual Studio versions like 2005 and 2008 that don't yet use the vcxproj project model based on MSBuild (it means Microsoft.Build interfaces won't help there). This issue as a whole surely requires special and detailed investigation.

At the same time, we are not completely unprepared for this turn of events. In his post (see the link earlier in this article), Carlos Quintero suggests separating the code directly using the IDE's APIs from all the other plugin code – business logic, user interfaces, etc. Should the necessity of upgrading to a new API occur, this approach will help you keep most of the code unchanged, simply creating a new "layer" for different IDE interfaces.

Our plugin – orplugins, to be more precise – had taken this path a few years ago already, although there had been a different reason behind it: we had had to provide support for a number of different IDEs besides Visual Studio. Although we haven't seen much commercial success from supporting these environments (RAD Studio \ C++ Builder in particular), this approach allowed us to use the plugin code as a basis for an independent tool for analyzing C++ projects and handling analysis logs – PVS-Studio Standalone. We hope that if it comes to that, migration from EnvDTE interfaces will be a bit less painful job for us.