To get a trial key
fill out the form below
Team License (a basic version)
Enterprise License (extended version)
* By clicking this button you agree to our Privacy Policy statement

Request our prices
New License
License Renewal
--Select currency--
USD
EUR
GBP
RUB
* By clicking this button you agree to our Privacy Policy statement

Free PVS-Studio license for Microsoft MVP specialists
* By clicking this button you agree to our Privacy Policy statement

To get the licence for your open-source project, please fill out this form
* By clicking this button you agree to our Privacy Policy statement

I am interested to try it on the platforms:
* By clicking this button you agree to our Privacy Policy statement

Message submitted.

Your message has been sent. We will email you at


If you haven't received our response, please do the following:
check your Spam/Junk folder and click the "Not Spam" button for our message.
This way, you won't miss messages from our team in the future.

>
>
Visual Studio Ceases Support of Add-Ins…

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

Aug 05 2014
Author:

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.

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.

Popular related articles
PVS-Studio for Java

Date: Jan 17 2019

Author: Andrey Karpov

In the seventh version of the PVS-Studio static analyzer, we added support of the Java language. It's time for a brief story of how we've started making support of the Java language, how far we've co…
How PVS-Studio Proved to Be More Attentive Than Three and a Half Programmers

Date: Oct 22 2018

Author: Andrey Karpov

Just like other static analyzers, PVS-Studio often produces false positives. What you are about to read is a short story where I'll tell you how PVS-Studio proved, just one more time, to be more atte…
The way static analyzers fight against false positives, and why they do it

Date: Mar 20 2017

Author: Andrey Karpov

In my previous article I wrote that I don't like the approach of evaluating the efficiency of static analyzers with the help of synthetic tests. In that article, I give the example of a code fragment…
The Evil within the Comparison Functions

Date: May 19 2017

Author: Andrey Karpov

Perhaps, readers remember my article titled "Last line effect". It describes a pattern I've once noticed: in most cases programmers make an error in the last line of similar text blocks. Now I want t…
Characteristics of PVS-Studio Analyzer by the Example of EFL Core Libraries, 10-15% of False Positives

Date: Jul 31 2017

Author: Andrey Karpov

After I wrote quite a big article about the analysis of the Tizen OS code, I received a large number of questions concerning the percentage of false positives and the density of errors (how many erro…
Technologies used in the PVS-Studio code analyzer for finding bugs and potential vulnerabilities

Date: Nov 21 2018

Author: Andrey Karpov

A brief description of technologies used in the PVS-Studio tool, which let us effectively detect a large number of error patterns and potential vulnerabilities. The article describes the implementati…
Appreciate Static Code Analysis!

Date: Oct 16 2017

Author: Andrey Karpov

I am really astonished by the capabilities of static code analysis even though I am one of the developers of PVS-Studio analyzer myself. The tool surprised me the other day as it turned out to be sma…
Static analysis as part of the development process in Unreal Engine

Date: Jun 27 2017

Author: Andrey Karpov

Unreal Engine continues to develop as new code is added and previously written code is changed. What is the inevitable consequence of ongoing development in a project? The emergence of new bugs in th…
Free PVS-Studio for those who develops open source projects

Date: Dec 22 2018

Author: Andrey Karpov

On the New 2019 year's eve, a PVS-Studio team decided to make a nice gift for all contributors of open-source projects hosted on GitHub, GitLab or Bitbucket. They are given free usage of PVS-Studio s…
The Ultimate Question of Programming, Refactoring, and Everything

Date: Apr 14 2016

Author: Andrey Karpov

Yes, you've guessed correctly - the answer is "42". In this article you will find 42 recommendations about coding in C++ that can help a programmer avoid a lot of errors, save time and effort. The au…

Comments (0)

Next comments
This website uses cookies and other technology to provide you a more personalized experience. By continuing the view of our web-pages you accept the terms of using these files. If you don't want your personal data to be processed, please, leave this site.
Learn More →
Accept