Одновременное использование Visual Studio 2010 в различных окружениях

Любите ли вы настраивать Visual Studio под свои личные предпочтения? Форматирование кода. Темы оформления. Набор расширений. Горячие клавиши. Расположение окон и панелей инструментов. Думаю, что этим занимается каждый разработчик, который заботится о своей продуктивности и комфорте работы. В итоге каждый из нас имеет базовый пакет настроек, специфичный для текущего окружения. В этом окружении можно чувствовать себя как рыба в воде, наизусть знать все горячие клавиши, расположение панелей. А среда разработки помогает вам быть продуктивнее, форматируя код и участвуя в рефакторинге. И казалось бы, уже ничего не может нарушить этой гармонии.

К сожалению, эту гармонию могут нарушить банальные жизненные обстоятельства. Например, вы решили поучаствовать во внешнем проекте, в котором определены свои правила оформления кода, отличные от ваших. Или вы выступаете с докладом и вас попросили изменить цвет и увеличить размер шрифта из-за особенностей местного проектора. Знакомо, не правда ли?

Что мы обычно делаем в приведенных выше ситуациях? Конечно мы открываем настройки Visual Studio и изменяем их в соответствии с нашими потребностями. В этом нет ничего плохого, если только вам не требуется это делать периодически. А как быть, если вы, например, с постоянной периодичностью читаете лекции студентам? Или переключаетесь между проектами с различными правилами оформления кода? В этих ситуациях вам потребуется постоянно изменять настройки среды разработки, что в конечном счете может стать сильно неэффективным. И в этом случае напрашивается логичное решение автоматизировать эти действия.

Решением проблемы могут быть два подхода:

  1. Использование заранее подготовленных настроек IDE для каждого случая.
  2. Использование нескольких изолированных экземпляров IDE.

Рассмотрим каждый из них.

Различные настройки среды разработки

Этот способ предполагает хранение на жестком диске нескольких конфигурационных файлов. Каждый файл соответствует отдельной ситуации. Получить такой конфигурационный файл очень просто – достаточно просто воспользоваться стандартным механизмом Import and Export Settings Wizard. С его помощью можно как сохранить текущие настройки в конфигурационный файл, так и восстановить состояние среды по существующему файлу.

Конфигурационные файлы являются обычными файлами XML, содержащие все настройки среды, указанные при экспорте. Теоретически вы можете автоматизировать настройку Visual Studio в соответствии с какими-то собственными алгоритмами. Для этого можно просто изменять содержимое конфигурационного файла. Однако мне очень сложно придумать, в каких ситуациях это действительно может быть востребовано.

После того, как вы подготовили несколько различных конфигураций, вы можете импортировать их, когда потребуется соответствующее окружение. Но использовать упомянутый диалог Import and Export Settings Wizard всякий раз, когда вам нужно сменить окружение – лишняя трата времени. Вместо этого можно создать несколько ярлыков на рабочем столе для запуска Visual Studio и указать для каждого из них путь до конфигурационного файла:

devenv.exe /ResetSettings "D:\VSConfig\settings1.vssettings"

Нетрудно догадаться, что в приведенном выше примере путь D:\VSConfig\settings1.vssetting как раз и указывает на конфигурационный файл. Теперь каждый ярлык Visual Studio на вашем рабочем столе запускает среду разработки с соответствующим окружением.

К плюсам данного решения можно отнести автоматизацию процесса загрузки новой конфигурации. Но такое решение обладает и рядом недостатков:

  • запуск Visual Studio с перезагрузкой настроек занимает более длительное время, чем обычный запуск среды разработки;
  • при использовании опции /ResetSettings очищаются внутренние кэши Visual Studio, что может негативно сказаться на скорости работы IDE уже в процессе написания кода;
  • файлы конфигурации всегда следует хранить в актуальном состоянии (если вы меняете настройки IDE в процессе работы и хотите сохранить их на будущее, вы должны обновить файл конфигурации на жестком диске);
  • неочевидна логика при запуске нескольких экземпляров VIsual Studio с различными настройками.

Использование нескольких изолированных экземпляров Visual Studio

Альтернативой приведенного выше способа является использование изолированных экземпляров Visual Studio. На самом деле изолированные экземпляры были созданы с целью отладки расширений для Visual Studio – вы разрабатываете собственное расширение и запускаете отладку. В этот момент запускается изолированный экземпляр Visual Studio, настройки которого являются независимыми от основной копии Visual Studio.

Этой особенностью как раз и можно воспользоваться для решения нашей задачи. Для этого нам нужно иметь несколько независимых изолированных экземпляров Visual Studio. Возможность создания изолированных экземпляров появляется после установки Visual Studio 2010 SDK. После установки SDK вам будет доступна утилита CreateExpInstance.exe, которая как раз и занимается управлением экземплярами Visual Studio.

Для создания нового экземпляра следует воспользоваться следующей командой:

CreateExpInstance.exe /VSInstance=10.0 /RootSuffix=Presentation

На самом деле эта утилита просто создает нужные ключи в реестре Windows. Параметр RootSuffix указывает имя создаваемого экземпляра. Это имя потребуется для запуска этого экземпляра. Аналогично использованию конфигурационных файлов, можно создать несколько ярлыков для запуска Visual Studio и указать параметры:

devenv.exe /RootSuffix Presentation

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

Плюсы подобного подхода очевидны – мы избавляемся от всех минусов предыдущего способа, создавая для каждого окружения свою изолированную среду. К минусам этого решения можно отнести необходимость установки Visual Studio 2010 SDK и применение специальной утилиты для управления экземплярами.

Заключение

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

Удачных экспериментов!