Локальное окружение проекта в MSVS

Question

[divanikus]

Подскажите пожалуйста, как у вас решается следующий вопрос.
Для разработки используется Visual Studio 2010 или WinSDK 7.1 (т.е. только компиляторы без среды). Необходимо для каждого проекта создать легко переносимое локальное окружение.

Т.е. допустим для разработки используется Qt4, но есть старые проекты, но все еще живые, использующие Qt3. И те и те библиотеки используют одну переменную окружения QTDIR. Если нам надо одновременно использовать ia32 и x64 билды, все становится еще сложнее. Каждый раз править окружение машины — неудобно. Править конфигурации проектов (vcxproj) при переходе с машины на машину — тоже неприемлемо.

Хотелось бы какого-либо элегантного решения, типа может локального файла с настройками проекта, в лучшем случае per configuration. В предыдущих версиях студии можно было использовать подключаемые Property Sheets (файлы vsprops), правда разрабы частенько забывают их подключать… В общем как-то не сильно удобнее.

В общем если есть опыт подобных решений, поделитесь пожалуйста :)

Answer 1

[Fahrenheit]

Property Sheets — это как раз и есть рекомендуемое решение, позволяет очень гибко кастомизировать параметры проектов (а благодаря возможности наследования получается минимальное дублирование настроек).
Они отлично работают и в VS10, и в VS2012

Comments

[divanikus]

А в VS2010 что-то переработали в этом плане? А то мне в VS2008 и ранее некоторые шероховатости не нравились…

[Fahrenheit]

Я пропустил VS2008. Но 2005 и 2010 работают аналогично, насколько я помню, за исключением каких-то изменений интерфейса. К сожалению, точнее не могу ответить, под рукой старых студий нету.

Answer 2

[Павел Сысолятин]

1. Самый дубовый вариант, на мой взгляд, сделать несколько *.bat файлов с прописыванием разных переменных окружения для MSVC. В случае запуска самой VS у devenv есть нужные параметры командной строки. Если же сборка идет из командной строки с использованием msbuild, то он тоже умеет все что нужно. В самих же проектах в настройках нужно просто использовать проставленные переменные окружения.
2. Другой вариант — Property Sheets, как уже было сказано ранее. С учетом что они поддерживают наследорвание и возможность определения своих макросов, сделать в них можно что угодно. Что с ними не очень удобно, так это рост количества конфигураций.

Comments

[Павел Сысолятин]

P.S. Чтобы разработчики не забывали подключать свойства, мы создаем несколько конфигураций для каждой из которых нужные «шиты» загружаются автоматически. Услованя загрузка в 2010 как раз присутсвует и очень удобна. Есть только один ньюанс (баг). При изменение свойств иногда нужно перезапускать студию чтобы изенение сохранились/подхватились.

[divanikus]

А можно немного поподробнее про условную загрузку?

[Павел Сысолятин]

Завтра с утра на работе в проект загляну, напишу. Давно не занимался свойствами.

Answer 3

[tbd]

внутри vcxproj файлы имеют формат msbuild'a
для задания различных условий можно использовать Conditional Constructs + Import Element

Comments

[divanikus]

Это я видел. А студия не затрет правки?

[tbd]

А студия не затрет правки?

Про это ничего не могу сказать.
От потери изменений спасает использование системы контроля версий (svn/git и тп)

[Павел Сысолятин]

Студия правки не затрет. Особенно если эти правки сделать в отдельном файле свойств. У нас сделано так:
К каждому отдельному проекту (отдельная библиотека, плагин или приложение) подключается свой универсальный Property Sheet. Например, sheet для приложения, собранного с использованием динамической линковки он такого вида:

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="PropertySheets">
    <Import Project="detail\_dynamic_debug.props" />
  </ImportGroup>
  <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="PropertySheets">
    <Import Project="detail\dynamic_release.props" />
  </ImportGroup>
  <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Debug|X64'" Label="PropertySheets">
    <Import Project="detail\dynamic_debug.props" />
  </ImportGroup>
  <ImportGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="PropertySheets">
    <Import Project="detail\dynamic_release.props" />
  </ImportGroup>

  <PropertyGroup>
    <TargetName>$(ProjectName)</TargetName>
    <OutDir>$(SolutionDir)$(Configuration)</OutDir>
  </PropertyGroup>
</Project>

В каталоге detail мы раскладываем разные файлы свойств для разных конфигураций.
Кроме того, для каждого отдельного солюшена у нас есть файл, solution.props который расположен всегда по одинаковому пути в каталоге любого солюшена и в котором прописывается путь до общих свойств (с помощью макроса) а также специфичные именно для данного проекта переменные, которые используются общими файлами свойств.
Все это позволяет гибко все настраивать для разных конфигураций даже в тех случаях когда разные проекты собираются с общими библиотеками и настройки этих библиотек зависит от того проекта для которого они используются. Когда мы добавляем новый проект или новую библиотеку, мы просто в нем 1 раз прописываем загрузку нужных списков свойств и забываем про это.