Как создавать, отлаживать и развертывать пакеты расширений Visual Studio

Около года назад мы опубликовали в нашем блоге серию статей о разработке плагинов для Visual Studio на C #. Мы недавно пересмотрели эти материалы и добавили новые разделы, а теперь приглашаем вас взглянуть на обновленную версию руководства в виде серии статей здесь, на DZone.

Другие статьи в серии можно найти здесь:

• Часть 1. Как создавать, отлаживать и развертывать пакеты расширений Visual Studio
• Часть 2. Использование объектной модели автоматизации Visual Studio
• Часть 3 — Использование команд Visual Studio
• Часть 4. Интеграция пользовательских инструментов Windows в среду Visual Studio
• Часть 5. Расширение диалога настроек Visual Studio
• Часть 6 — Структура модели проекта Visual Studio

Создание пакетов расширений (плагинов) для Microsoft Visual Studio IDE на первый взгляд кажется довольно простой задачей. Доступна отличная документация MSDN, а также различные статьи, примеры и множество других источников на эту тему. Но, в то же время, это может показаться сложной задачей, когда на этом пути встречается неожиданное поведение. Хотя можно сказать, что такие проблемы довольно распространены в любой задаче программирования, тема разработки плагинов IDE до сих пор не была полностью рассмотрена.

Мы разработали PVS-Studioстатический анализатор кода. Хотя сам инструмент предназначен для разработчиков на C ++, довольно большой его фрагмент написан на C #. Когда мы только начали разработку нашего плагина, Visual Studio 2005 считалась самой современной IDE. Однако, с выпуском Visual Studio 2012 некоторые могут сказать, что Visual Studio 2005 больше не актуален, но мы по-прежнему предоставляем поддержку этой версии в нашем инструменте. За время нашей поддержки различных версий Visual Studio и изучения возможностей среды мы накопили практический опыт о том, как правильно (а тем более неправильно!) Разрабатывать плагины IDE. Поскольку держать все эти знания внутри нас стало невыносимо, мы решили опубликовать их здесь. Некоторые из наших решений, которые сейчас кажутся совершенно очевидными, были открыты в течение нескольких лет.Те же проблемы все еще могут преследовать других разработчиков плагинов.

В этой серии статей мы рассмотрим следующие темы:

• Основная информация о создании и отладке подключаемых модулей MSVS и поддержке этих проектов расширяемости для нескольких версий Visual Studio в общей базе исходного кода.
• Обзор объектной модели автоматизации и различных классов инфраструктуры управляемых пакетов (MPF).
• Информация о расширении интерфейса IDE через классы API объектной модели автоматизации (EnvDTE) и MPF (Managed Package Framework) с помощью пользовательских меню, панелей инструментов, окон и страниц параметров.
• Обзор модели проекта Visual Studio, Atmel Studio IDE, основанной на изолированной оболочке Visual Studio, как пример взаимодействия с пользовательскими моделями проектов сторонних производителей.
• Информация о том, как использовать модель проекта Visual C ++ для сбора данных, необходимых для работы внешнего препроцессора / компилятора, таких как аргументы и параметры компиляции для различных платформ и конфигураций.

Более подробные ссылки на каждую из статей серии доступны в конце каждой статьи со ссылками на библиотеку MSDN и другие внешние ресурсы.

Статьи будут посвящены разработке расширений только для Visual Studio 2005 и более поздних версий. Это ограничение отражает то, что PVS-Studio также поддерживает интеграцию с Visual Studio, начиная только с версии 8 (Visual Studio 2005). Основная причина этого заключается в том, что для Visual Studio 2005 была введена новая модель API расширяемости, и эта новая версия не обратно совместима с предыдущими API расширяемости IDE.

Создание, отладка и развертывание пакетов расширений для Microsoft Visual Studio 2005/2008/2010/2012

Этот элемент содержит обзор нескольких различных методов расширения функциональных возможностей Visual Studio IDE. Создание, отладка, регистрация и развертывание пакетов расширений Visual Studio для конечных пользователей будут подробно объяснены.

Создание и отладка модулей расширения VSPackage для Visual Studio и Visual Studio Isolated Shell

Существует несколько способов расширения возможностей Microsoft Visual Studio. На самом базовом уровне можно автоматизировать простые рутинные действия пользователя с помощью макросов. Дополнительный подключаемый модуль может использоваться для получения доступа к объектам пользовательского интерфейса среды, таким как команды меню, окна и т. Д. Расширение внутренних редакторов IDE возможно с помощью компонентов MEF (Managed Extensibility Framework) (начиная с MSVS 2010). ). Наконец, плагин типа пакета расширения (известный как VSPackage) лучше всего подходит для интеграции больших независимых компонентов в Visual Studio. VSPackage позволяет объединить автоматизацию среды через Automation Object Mode l с использованием Managed Package Frameworkклассы (такие как пакет). Фактически, хотя сама Visual Studio предоставляет только базовые компоненты интерфейса и службы, такие стандартные модули, как Visual C ++ или Visual C #, сами реализованы как расширения IDE.

В более ранних версиях плагин PVS-Studio (точнее, версии 1.xx и 2.xx, когда он еще назывался Viva64) существовал как пакет надстройки. Начиная с PVS-Studio 3.0, он был переработан как VSPackage, потому что функциональность, которую могла обеспечить надстройка, стала недостаточной для выполняемых задач, а также процесс отладки был довольно неудобным. В конце концов, мы хотели иметь собственный логотип на заставке Visual Studio!

VSPackage также предоставляет средства для расширения самой модели автоматизации, регистрируя в ней определенные пользователем объекты автоматизации. Такие объекты автоматизации пользователей станут доступны через ту же модель автоматизации для других пользовательских пакетов расширения, предоставляя этим пакетам доступ к вашим пользовательским компонентам. Это, в свою очередь, позволяет сторонним разработчикам добавлять поддержку новых языков программирования и компиляторов через такие расширения в IDE, а также предоставлять интерфейсы для автоматизации этих новых компонентов.

Помимо расширения самой среды Visual Studio, расширения VSPackage можно использовать для добавления новых функций в изолированные \ интегрированные оболочки Visual Studio. Изолированные \ интегрированные оболочки предоставляют любому стороннему разработчику возможность повторно использовать базовые компоненты интерфейса и службы Visual Studio (такие как редактор кода, система автозаполнения и т. Д.), А также реализовывать поддержку других пользовательских моделей проектов. и \ или компиляторы. Такой дистрибутив не будет включать ни один из проприетарных языковых модулей Microsoft (таких как Visual C ++, Visual Basic и т. Д.), И он может быть установлен конечным пользователем, даже если его или ее система не содержит предыдущей установки Visual Studio.

После установки изолированное приложение оболочки останется отдельным объектом, даже если система содержит предыдущую установку Visual Studio, но интегрированное приложение оболочки будет объединено в предустановленную версию. В случае, если разработчик изолированной \ интегрированной оболочки расширяет модель автоматизации Visual Studio, добавляя интерфейсы к своим пользовательским компонентам, все остальные разработчики расширений VSPackage также смогут обрабатывать такие компоненты. Atmel Studio, IDE, разработанная для разработки встраиваемых систем, является примером приложения Visual Studio Isolated Shell. Atmel Studio использует собственную модель проекта, которая, в свою очередь, сама является реализацией стандартной модели проекта Visual Studio для MSBuild и конкретной версии компилятора GCC.

Проекты для подключаемых модулей VSPackage: создание пакета расширения

Давайте рассмотрим создание плагина пакета Visual Studio (расширение VSPackage). В отличие от дополнительных модулей, разработка пакетов расширений VS требует установки Microsoft Visual Studio SDK для целевой версии IDE, то есть отдельный SDK должен быть установлен с каждой версией Visual Studio, для которой разрабатывается расширение. В случае расширения, предназначенного для Visual Studio Isolated \ Integrated Shell, потребуется SDK для версии Visual Studio, на которой основана такая оболочка.

Мы будем изучать разработку расширений для изолированных версий оболочек Visual Studio и Visual Studio 2010 на основе версий 2005, 2008, 2009 и 2012 годов. При установке Visual Studio SDK в диспетчер шаблонов VS добавляется стандартный шаблон проекта для пакета Visual Studio (на странице «Другие типы проектов -> Расширяемость»). Если этот параметр выбран, этот шаблон будет генерировать базовый проект MSBuild для пакета расширения, позволяя заранее указать несколько параметров, таких как язык программирования, и автоматически генерировать несколько компонентов-заглушек для общих элементов пользовательского интерфейса, таких как элементы меню. редактор, окно инструментов пользователя и т. д.

Мы будем использовать проект C # VSPackage (csproj), который является проектом для управляемой библиотеки динамических ссылок (DLL). Соответствующий проект csproj MSBuild для этой управляемой сборки также будет содержать несколько узлов XML, специфичных для пакета Visual Studio, таких как компилятор VSCT и IncludeinVSIX (в более поздних версиях IDE).

Основной класс пакета расширения должен быть унаследован от пакета Microsoft.VisualStudio.Shell.Package . Этот базовый класс предоставляет управляемые оболочки для API-интерфейсов взаимодействия IDE, реализация которых требуется из полнофункционального пакета расширений Visual Studio.

public sealed class MyPackage: Package
{
  public MyPackage ()
  {}
  ...
}

Класс Package позволяет переопределять его базовый метод Initialize. Этот метод получает управление выполнением в момент инициализации пакета в текущем сеансе IDE.

protected override void Initialize()
{
  base.Initialize();

  ...
}

Инициализация модуля будет происходить, когда он вызывается в первый раз, но он также может запускаться автоматически, например, после запуска IDE или когда пользователь входит в предварительно определенное состояние контекста пользовательского интерфейса среды.

Знание времени инициализации и завершения работы пакета имеет решающее значение. Вполне возможно, что разработчик запросит некоторые функциональные возможности Visual Studio в тот момент, когда он все еще недоступен для пакета. Во время разработки PVS-Studio мы столкнулись с несколькими такими ситуациями, когда среда «наказывала нас» за то, что мы этого не понимали; Например, нам не разрешено «прямо» отображать окна сообщений после входа Visual Studio в процесс завершения работы.

Отладка пакетов расширения: экспериментальный экземпляр

Задача отладки подключаемого модуля или расширения, предназначенного для IDE, не является тривиальной. Довольно часто такая среда сама используется для разработки и отладки плагина. Подключение нестабильного модуля к этой IDE может привести к нестабильности самой среды. Необходимость удаления разрабатываемого модуля из среды IDE перед каждым сеансом отладки, что, в свою очередь, часто требует его перезапуска, также является серьезным неудобством (среда IDE может заблокировать библиотеку DLL, которая должна быть заменена более новой версией для отладки).

Следует отметить, что процесс отладки VSPackage в этом аспекте существенно проще, чем в пакете надстроек. Это было одной из причин изменения типа проекта плагина PVS-Studio.

VSPackage решает вышеупомянутые проблемы разработки и отладки, используя механизм экспериментального экземпляра Visual Studio. Такой экспериментальный экземпляр можно легко запустить, передав специальный аргумент командной строки:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\
  Common7\IDE\devenv.exe" /RootSuffix Exp

Экспериментальный экземпляр среды использует отдельный независимый куст реестра Windows (так называемый экспериментальный куст) для хранения всех своих настроек и данных регистрации компонентов. Таким образом, любые изменения в настройках среды IDE или изменения в регистрационных данных ее компонентов, которые были сделаны внутри экспериментального куста, не будут влиять на экземпляр, который используется для разработки модуля (это ваш основной регулярный экземпляр, который используется по умолчанию).

Visual Studio SDK предоставляет специальный инструмент для создания или сброса таких экспериментальных экземпляров: CreateExpInstance . Чтобы создать новый экспериментальный улей, он должен быть выполнен с этими аргументами:

CreateExpInstance.exe /Reset /VSInstance=10.0 /RootSuffix=PVSExp

Выполнение этой команды создаст новый экспериментальный куст реестра с суффиксом PVSExp в его имени для 10-й версии IDE (Visual Studio 2010), а также предварительно сбросит все его настройки до значений по умолчанию. Путь к реестру для этого нового экземпляра будет выглядеть следующим образом:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0PVSExp

Хотя суффикс Exp используется по умолчанию для отладки пакетов внутри проекта шаблона VSPackage, другие экспериментальные ульи с уникальными именами также могут быть созданы разработчиком по желанию. Чтобы запустить экземпляр среды для улья, который мы создали ранее (содержащего PVSExp в его имени), следует использовать следующие аргументы:

"C:\Program Files (x86)\Microsoft Visual Studio 10.0\
  Common7\IDE\devenv.exe" /RootSuffix PVSExp

Возможность создания нескольких различных экспериментальных ульев на одной локальной рабочей станции может быть весьма полезной, например, для обеспечения одновременной и изолированной разработки нескольких пакетов расширений.

После установки пакета SDK в группе меню программы Visual Studio создается ссылка для сброса экспериментального экземпляра по умолчанию для этой версии IDE (например, «Сброс экспериментального экземпляра Microsoft Visual Studio 2010»).

В случае расширения, нацеленного на изолированную оболочку, проблемы с «повреждением» среды разработки не имеют значения, и поэтому нет необходимости в использовании экспериментального экземпляра. В любом случае, чем быстрее вы выясните, как работает среда отладки, тем меньше проблем возникнет при понимании того, как инициализация плагина работает во время разработки.

Регистрация и развертывание пакетов расширений Visual Studio

Регистрация пакета расширения VS требует регистрации самого пакета, а также регистрации всех компонентов, которые он интегрирует в IDE (например, пункты меню, страницы параметров, пользовательские окна и т. Д.). Регистрация выполняется путем создания записей, соответствующих этим компонентам, в основном кусте системного реестра Visual Studio.

Вся информация, необходимая для регистрации, помещается после сборки вашего VSPackage в специальный файл pkgdef в соответствии с несколькими специальными атрибутами основного класса вашего пакета (который сам должен быть подклассом класса MPF «Package»). Pkgdef также можно создать вручную с помощью CreatePkgDef . Этот инструмент собирает всю необходимую информацию о регистрации модуля из этих специальных атрибутов с помощью отражения .NET. Давайте подробно изучим эти регистрационные атрибуты.

PackageRegistration атрибут указывает регистрационный инструмент , что этот класс действительно является пакет расширения Visual Studio. Только если этот атрибут обнаружен, инструмент выполнит поиск дополнительных.

 [PackageRegistration(UseManagedResourcesOnly = true)]

 [Guid("a0fcf0f3-577e-4c47-9847-5f152c16c02c")]

 [InstalledProductRegistration("#110", "#112", "1.0", 
  IconResourceID = 400)]

[ProvideAutoLoad("D2567162-F94F-4091-8798-A096E61B8B50")]

 [ProvideMenuResource("Menus.ctmenu", 1)]

[DefaultRegistryRoot("Software\\Microsoft\\VisualStudio\\9.0")]

[AttributeUsage(AttributeTargets.Class, Inherited = true,
  AllowMultiple = false)]
    public class CustomRegistrationAttribute : RegistrationAttribute
    {
    }

RegPkg.exe /root:Software\Microsoft\VisualStudio\9.0Exp
  "/pkgdeffile:obj\Debug\PVS-Studio-vs2008.pkgdef"
  "C:\MyPackage\MyPackage.dll"

Devenv.exe /setup

VSIXInstaller.exe MyPackage.vsix

VSIXInstaller.exe /uninstall: 009084B1-6271-4621-A893-6D72F2B67A4D

<Content Include="MyPackage.pdb">
  <IncludeInVSIX>true</IncludeInVSIX>
</Content>

[ProvideLoadKey("Standard", "9.99", "MyPackage", "My Company", 100)]