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.

1. Visual Studio Ceases Support of Add-Ins in
Community Previews 14
Author: Paul Eremeev
Date: 05.08.2014
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, this 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.

2. 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.