Не так давно Microsoft показала широкой общественности, как будет выглядеть следующая версия Visual Studio, сейчас известная под именем Visual Studio 14 CTP (Community Technology Preview). После установки последней доступной версии CTP, одним из первых, что сразу бросилось мне в глаза, стало исчезновение пункта Add-In Manager в меню Tools. Прошёл уже год с тех пор, как Add-In плагины были официально объявлены deprecated в Visual Studio 2013, и вот похоже, что в новой версии студии их поддержка будет окончательно прекращена.
Для тех, кто незнаком с нюансами разработки плагинов для Visual Studio, следует уточнить, что под Add-In'ами в данном контексте мы понимаем разновидность модулей расширения (проще - plug-in'ов) для Visual Studio. Данный тип плагинов появился в Visual Studio достаточно давно. С тех пор появились и другие возможности расширить стандартный функционал Visual Studio, как дополняющие то, что могут делать Add-In'ы, так и дублирующие их возможности, но в более удобном для разработчиков и конечных пользователей виде (MPF, VSPackage, MEF). Не станем сейчас заострять внимание на этих моментах, скажу лишь, что вы можете более детально изучить вопрос расширения среды Visual Studio в нашей серии статей, посвящённой этой тематике.
Продукт PVS-Studio, помимо непосредственно самого C++ анализатора, включает в себя плагины для интеграции в несколько разных IDE, и в первую очередь, конечно, в Visual Studio. Когда-то, во времена первых версий PVS-Studio, для интеграции с Visual Studio мы использовали Add-In плагины. Однако уже достаточно давно мы мигрировали все наши проекты на формат плагина VSPackage.
Понятно, что для разработчиков расширений к Visual Studio, которые всё ещё используют Add-In для интеграции в среду разработки (а такие плагины, как ни странно, до сих пор существуют и развиваются), наступает время мигрировать свои проекты на более современный формат. Однако меня больше заинтересовал вопрос – может ли планируемый отказ Microsoft от дальнейшей поддержки Add-in создать какие-то проблемы для нас – т.е. тех, кто уже использует формат VSPackage в своих продуктах.
На первый взгляд – проблем возникнуть не должно. Ведь маловероятно, что в обозримом будущем Microsoft откажется от поддержки VSPackage, хотя бы потому, что значительная часть стандартных компонентов Visual Studio реализована как раз в таком формате. Однако комментарий к данной новости от Карлоса Квинтеро (Carlos Quintero, MVP, специализирующийся на тематике Microsoft Extensibility), заставил меня задуматься и взглянуть на данную проблему под несколько другим углом.
В частности, нашему плагину для запуска статического анализа на файлах проекта требуется собрать об этих файлах всю информацию, касающуюся их построения – параметры запуска компилятора, параметры конфигураций проекта и т.п. Для этого плагин использует интерфейсы из объекта EnvDTE – "верхнего" интерфейса модели автоматизации Visual Studio. Однако, модель автоматизации Visual Studio изначально создавалась как раз для поддержки макросов и Add-In'ов, и появилась она ещё в первой Visual Studio.NET 2002, VSPackage появились несколько позже. Итак, поддержка макросов исчезла в Visual Studio 2012, поддержка Add-in'ов скорее всего пропадёт в грядущей версии... что же дальше? Не решит ли Microsoft в один "прекрасный момент" отказаться и от EnvDTE целиком, тем более всё больше компонентов Visual Studio уже используют WPF, MEF, интерфейсы MPF (тот же Package, описывающий VSPackage плагин) и службы среды. EnvDTE же может стать (а возможно, и уже стал) лишним промежуточным слоем, оставленным лишь для совместимости.
Нужно сказать, что мы серьёзно ещё не рассматривали вариант полного отказа от интерфейсов из EnvDTE. Я лично, например, не представляю на данный момент, как можно более удобно (ну или хотя бы так же удобно) обходить дерево проекта, получать списки всех необходимых файлов и их параметры сборки, без использования таких интерфейсов, как VCProject и ProjectItem. Тем более, что конкретно PVS-Studio должна поддерживать такие старые версии Visual Studio, как 2005 и 2008, в которых ещё не используется проектная модель vcxproj, основанная на MSBuild (т.е. интерфейсы из Microsoft.Build там не помогут). Это вопрос, безусловно, требует отдельного и детального изучения.
Но одновременно нельзя сказать, что мы совсем не готовы к такому развитию событий. В своей заметке (на которую я давал ссылку выше), Карлос Квинтеро предлагает отделять код, непосредственно использующий API студии от остального кода плагина – бизнес логики, пользовательских интерфейсов и т.п. При необходимости перехода на новый API, такой подход позволит сохранить большую часть кода неизменной, создав лишь новую "прослойку" для других интерфейсов среды.
Наш плагин (или говоря точнее - плагины) уже пошли по аналогичному пути ещё несколько лет назад, правда вызвано это было другой причиной - необходимостью обеспечить поддержку нескольким средам разработки, помимо Visual Studio. И хотя коммерческий результат от поддержки этих сред (и в частности, RAD Studio \ C++ Builder) оставляет желать лучшего, данный подход позволил нам в дальнейшем легко создать на основе кода плагинов независимый инструмент для анализа C++ проектов и работы с логами проверки – PVS-Studio Standalone, и в будущем, если до этого дойдёт, позволит нам чуть менее болезненно провести миграцию с интерфейсов EnvDTE.