Переменная Macros/Environment в файлах .sln и .vcproj для Visual studio

У меня две аналогичные проблемы:

a) У меня есть решение, которое включает в себя несколько проектов, и я хочу легко переключаться с местоположением проекта, устанавливая некоторую переменную среды/макрос. В качестве примера этот проект может быть расположен в \ SolutionDir\Dir1\или\SolutionDir\Dir2 \ Итак, я хочу указать, что он должен быть расположен в \SolutionDir\$(Var) и просто установить переменную.

Есть ли в Visual Studio способ сборки?

В настоящее время я знаю только два решения - отредактируйте файл .sln вручную/программно, чтобы найти этот проект и установить правильный путь.

Я не смог использовать переменную среды в файле .sln.

b) У меня есть проект, который включает в себя файлы ресурсов (.rc и .h). Я хочу иметь возможность установить их местоположение через другую переменную среды или макрос.

Что-то вроде \ProjectDir\$(Var2)\resource.rc

Я нашел многообещающую информацию о листах свойств, но Visual Studio не расширяет макросы, когда я их использую в теге File в .vcproj.

Спасибо за любые идеи, как решить эту проблему.

С уважением, Виктор

Ответ 1

Просто используйте переменную окружения в соответствующем поле:

OutputDirectory="$(MyEnvVariableName)\Bin"

Один трюк заключается в том, что вам нужно перезапустить среду Visual Studio при каждом изменении переменной.

Существует статья MSDN именно об этом: Как использовать переменные среды в сборке

Ответ 2

Я думаю, что у меня есть та же цель, что и вы: я хочу использовать переменные среды для поиска некоторых проектов в файле решения (.sln) и использовать некоторые переменные среды для поиска некоторых файлов в моих проектах.

Я нашел способ сделать это, и он отлично работает для меня (с Visual Studio 2005): - отредактируйте файл .sln с помощью текстового редактора и используйте переменные среды со следующим синтаксисом% MyEnvironmentVariable% - отредактируйте файлы .vcproj и замените путь на нужные файлы некоторыми переменными со следующим синтаксисом $(MyEnvironmentVariable).

Надеюсь, что это поможет... Сирил

Ответ 3

Лучший способ добиться того, что вы описали в b), - использовать листы свойств. Посмотрите также этот очень аналогичный вопрос.

Я нашел многообещающую информацию о листы свойств, но Visual studio не расширяет макросы, когда я использую их в теге Файл в .vcproj.

Я не уверен, какую версию VS вы используете. VS2008 позволяет определить, например, каталог include, такой как: "$ (OpenCVInclude)\cxcore\include". Я использую это все время. OpenCVInclude - это макрос, определенный в листе свойств.

Что касается вопроса а), я думаю, что нет "чистого" способа делать то, что вы хотите. В качестве альтернативы вы можете настроить менеджера конфигурации:

Включить все проекты в решение.
Назовите проект по-разному, например, на основе OEM.
Для каждого проекта определите конфигурации выпуска и отладки в решении
В "Build- > Configuration Manager" Вы можете проверить или снять флажок столбца "Build" для каждой конфигурации. Проверьте "сборку" для соответствующего проекта.

Ответ 4

Я не уверен, что вы строите только проекты на С++ или если вы также создаете проекты С#\VB, но одна из замечательных особенностей Visual Studio - это все проекты, которые действительно являются проектами MSBuild. Если вы редактируете проект в текстовом редакторе, вы увидите, что в конце проекта он импортирует файл .targets. Если вы отслеживаете и находите следовать импорту, вы обнаружите, что почти все проекты VS импортируют Microsoft.Common.Targets. Microsoft.Common.Targets импортирует Custom.Before.Microsoft.Common.Targets. Используя этот импорт, вы можете импортировать свой собственный файл целей своими собственными действиями.

У меня, например, есть целевой файл, который имеет общее свойство, определенное для всех проектов в решении, и пользовательское событие пост-сборки, которое обрабатывается в конце каждого проекта.

Используя этот метод расширения и создавая настраиваемые конфигурации в решении, помимо стандартного release\debug, вы должны иметь возможность создавать как можно более сложную конфигурацию сборки.

Ответ 5

(а) Кирилл дает достойное решение того, что вы просили. Другой способ - сохранить ваши сменные настройки в одном общем месте. Обратите внимание, что это не будет работать для файлов, отличных от msbuild, таких как *.sln и *.vcproj(до VS 2010).

Файлы проекта: ... $ (ChangeableDir)\foo.cs

Common.targets: ChangeThis ...

Однако я не думаю, что это отличный способ сделать что-то. Если различия между тем, что вы строите, являются большими функциональными возможностями, вам следует подумать о создании ветки в вашей системе управления версиями. OTOH, если различия незначительны - например, жестко закодированные строки - тогда это приводит к вашему второму вопросу...

(б) Тип управления ресурсами, который вы описываете, по сути является той же проблемой, с которой сталкиваются люди, локализующие свой проект на разных языках. К счастью, прямая поддержка встроена в Visual Studio с 2005 года. Проверьте предыдущие вопросы, такие как: Локализация в Visual Studio 2008