У меня две аналогичные проблемы:
a) У меня есть решение, которое включает в себя несколько проектов, и я хочу легко переключаться с местоположением проекта, устанавливая некоторую переменную среды/макрос. В качестве примера этот проект может быть расположен в \ SolutionDir\Dir1\или\SolutionDir\Dir2 \ Итак, я хочу указать, что он должен быть расположен в \SolutionDir\$(Var) и просто установить переменную.
Есть ли в Visual Studio способ сборки?
В настоящее время я знаю только два решения - отредактируйте файл .sln вручную/программно, чтобы найти этот проект и установить правильный путь.
Я не смог использовать переменную среды в файле .sln.
b) У меня есть проект, который включает в себя файлы ресурсов (.rc и .h). Я хочу иметь возможность установить их местоположение через другую переменную среды или макрос.
Что-то вроде \ProjectDir\$(Var2)\resource.rc
Я нашел многообещающую информацию о листах свойств, но Visual Studio не расширяет макросы, когда я их использую в теге File в .vcproj.
Спасибо за любые идеи, как решить эту проблему.
С уважением, Виктор
Просто используйте переменную окружения в соответствующем поле:
OutputDirectory="$(MyEnvVariableName)\Bin"
Один трюк заключается в том, что вам нужно перезапустить среду Visual Studio при каждом изменении переменной.
Существует статья MSDN именно об этом: Как использовать переменные среды в сборке
Я думаю, что у меня есть та же цель, что и вы: я хочу использовать переменные среды для поиска некоторых проектов в файле решения (.sln) и использовать некоторые переменные среды для поиска некоторых файлов в моих проектах.
Я нашел способ сделать это, и он отлично работает для меня (с Visual Studio 2005): - отредактируйте файл .sln с помощью текстового редактора и используйте переменные среды со следующим синтаксисом% MyEnvironmentVariable% - отредактируйте файлы .vcproj и замените путь на нужные файлы некоторыми переменными со следующим синтаксисом $(MyEnvironmentVariable).
Надеюсь, что это поможет... Сирил
Лучший способ добиться того, что вы описали в b), - использовать листы свойств. Посмотрите также этот очень аналогичный вопрос.
Я нашел многообещающую информацию о листы свойств, но Visual studio не расширяет макросы, когда я использую их в теге Файл в .vcproj.
Я не уверен, какую версию VS вы используете. VS2008 позволяет определить, например, каталог include, такой как: "$ (OpenCVInclude)\cxcore\include". Я использую это все время. OpenCVInclude - это макрос, определенный в листе свойств.
Что касается вопроса а), я думаю, что нет "чистого" способа делать то, что вы хотите. В качестве альтернативы вы можете настроить менеджера конфигурации:
Я не уверен, что вы строите только проекты на С++ или если вы также создаете проекты С#\VB, но одна из замечательных особенностей Visual Studio - это все проекты, которые действительно являются проектами MSBuild. Если вы редактируете проект в текстовом редакторе, вы увидите, что в конце проекта он импортирует файл .targets. Если вы отслеживаете и находите следовать импорту, вы обнаружите, что почти все проекты VS импортируют Microsoft.Common.Targets. Microsoft.Common.Targets импортирует Custom.Before.Microsoft.Common.Targets. Используя этот импорт, вы можете импортировать свой собственный файл целей своими собственными действиями.
У меня, например, есть целевой файл, который имеет общее свойство, определенное для всех проектов в решении, и пользовательское событие пост-сборки, которое обрабатывается в конце каждого проекта.
Используя этот метод расширения и создавая настраиваемые конфигурации в решении, помимо стандартного release\debug, вы должны иметь возможность создавать как можно более сложную конфигурацию сборки.
(а) Кирилл дает достойное решение того, что вы просили. Другой способ - сохранить ваши сменные настройки в одном общем месте. Обратите внимание, что это не будет работать для файлов, отличных от msbuild, таких как *.sln и *.vcproj(до VS 2010).
Файлы проекта: ... $ (ChangeableDir)\foo.cs
Common.targets: ChangeThis ...
Однако я не думаю, что это отличный способ сделать что-то. Если различия между тем, что вы строите, являются большими функциональными возможностями, вам следует подумать о создании ветки в вашей системе управления версиями. OTOH, если различия незначительны - например, жестко закодированные строки - тогда это приводит к вашему второму вопросу...
(б) Тип управления ресурсами, который вы описываете, по сути является той же проблемой, с которой сталкиваются люди, локализующие свой проект на разных языках. К счастью, прямая поддержка встроена в Visual Studio с 2005 года. Проверьте предыдущие вопросы, такие как: Локализация в Visual Studio 2008