Как вы определяете переменную в стиле Makefile в решении для использования в нескольких проектах (VS 2008)?

Я работаю над решением Visual Studio 2008 с несколькими проектами C # и некоторыми проектами C ++ и хочу использовать события после сборки для выполнения некоторых инструментов командной строки сторонних поставщиков. Эти события после сборки необходимы в нескольких проектах.

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

$ (ToolsDir) \ $ (PackageBuilder) $ (ThirdPartyDllFolder) $ (SharedOutputFolder)

Когда я разрабатывал для UNIX и использовал make-файлы для выполнения сборки, я смог определить переменную в make-файле высокого уровня и унаследовать ее от make-файлов-потомков. Таким образом, я мог бы направить весь вывод в определенное место или искать в определенном месте библиотеку и т. Д.

Есть ли что-то подобное, что можно сделать с помощью решений Visual Studio, например, определить что-то вроде переменной среды, а затем ссылаться на нее в событии после сборки на уровне проекта?

РЕДАКТИРОВАТЬ: Я использую переменные среды Windows прямо сейчас, но предпочел бы что-то, что не требует настройки, кроме простой загрузки кода и его создания.


msbuild projects-and-solutions visual-studio-2008
person Jeremy    schedule 19.05.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы рассматривали переменные среды в Windows? Я знаю, что это не совсем то же самое, но вы можете установить их с помощью пакетного файла и выполнить этот пакетный файл после сборки.

person Scott Anderson    schedule 19.05.2009
comment
Скотт, да, я действительно использую этот метод, но я ищу метод, при котором разработчик мог бы просто загрузить исходный код на чистую машину и построить его без дополнительных действий. - person Jeremy; 19.05.2009

arrow_upward
1
arrow_downward

Некоторое время назад у меня была аналогичная проблема. Моим первым «решением» было создание инструмента, который создавался и запускался, когда разработчик получал первое «получение» из репозитория. Это было некрасиво, и это был еще один шаг, но только один раз.

Я отказался от этого, и теперь у нас есть другой метод. Мы помещаем сторонние инструменты в репозиторий svn (отличный от нашего источника) и требуем определенной иерархии и имени для того, где этот репозиторий находится по отношению к корню нашей базы кода. Таким образом, мы можем уверенно использовать относительные пути на этапах после сборки или в других частях.

Я согласен с тем, что это небольшая слабость в инструментах сборки MS.

person Tim    schedule 01.02.2010