Я пытаюсь настроить файл common.targets с некоторыми общими целями msbuild, которые я хочу использовать в своих командных сборках и, следовательно, импортировать в мои файлы TFSBuild.proj. Мне интересно, как лучше всего этого добиться? Нужно ли мне хранить common.targets рядом с каждым файлом TFSBuild.proj и, следовательно, иметь дубликаты файла target для каждой командной сборки или есть другой способ? Я бы предпочел не помещать целевой файл на каждую из машин сборки.
Где мне хранить общие цели для командных сборок?
comment
Здесь есть несколько хороших ответов. Почему бы вам не прокомментировать, почему они не работают, или не согласитесь?
- person Vaccano schedule 02.06.2009
comment
Ты прав. Сделано так. Спасибо за Ваш ответ.
- person Fadeproof schedule 02.06.2009
Ответы (4)
Перед вызовом TFSBuild.proj в Team Build есть этап начальной загрузки, на котором из системы управления версиями загружаются только TFSBuild.proj и другие файлы в том же каталоге. Поэтому, если вы хотите, чтобы ваш целевой файл находился под контролем источника, вам нужно поместить его в то же место, что и TFSBuild.proj.
Я никогда не пробовал, но вы могли бы поместить целевой файл в общий сетевой ресурс и импортировать его, используя общий ресурс unc. Что-то типа
<Import Project="\\anothermachine\share\something.targets"/>
Но для этого потребуется, чтобы учетная запись сборки и все люди, выполняющие сборки для настольных компьютеров, имели доступ к этому сетевому ресурсу.
person
Erling Paulsen
schedule
02.04.2009
Поместите его в обычное место, которое вам нравится в системе управления версиями. Перед использованием целей выполните получение из файла TFSBuild.proj следующим образом:
<PropertyGroup>
<!--Path to the TFS Command Line (used for checkin and out)-->
<TxTf>"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\tf"</TxTf>
<WorkingDirectory>C:\YourPathHere<WorkingDirectory>
<CustomProjTFSDir>"$/YourProj/YourCustomProjPath"</CustomProjTFSDir>
</PropertyGroup>
<Exec WorkingDirectory="$(WorkingDirectory)"
Command="$(TxTf) get $(CustomProjTFSDir)"/>
Ключом к этой работе является настройка рабочей области для пользователя вашего агента сборки, которая указывает на ваши пользовательские материалы. Этот каталог НЕ должен находиться в том же пространстве, что и ваши обычные сборки.
Vaccano
person
Vaccano
schedule
11.05.2009
Куда вы позвонили Exec? Если я помещаю его в цель, сначала выполняется попытка импорта, но она не выполняется. Если я попробую поставить прямо под корень ‹Project›, то выйдет ошибка. Как я могу выполнить доступ к файлу перед попыткой его импорта?
- person Elezar; 23.06.2014
@Elezar - 5 лет назад я мог бы ответить на ваш вопрос. Я уже давно мало что делал с MS Build. Сейчас не припомню. Прости.
- person Vaccano; 24.06.2014
Хорошо, я понял, что это был долгий шанс, учитывая, сколько лет этому ответу. Тем не менее, спасибо за ответ!
- person Elezar; 24.06.2014
Цель обычного файла .targets - уменьшить дублирование ваших скриптов. Если у вас есть несколько копий этого файла в системе управления версиями, что произойдет, когда вам нужно будет изменить их (возможно, для обновления пути .exe)? Лично я предпочитаю отдельное место для общих файлов, на которые могут ссылаться любые / все другие сценарии сборки. Единственным недостатком этого является то, что вы, скорее всего, жестко запрограммируете путь к этому файлу.
person
Pedro
schedule
02.03.2009
Вы можете хранить их вместе с целями MS в $ Volume \ Program Files \ MSBuild. Преимущество этого заключается в том, что вы можете создать относительный путь, используя встроенные известные метаданные "$ (MSBuildExtensionsPath) \ Path \ To \ Your \ Targets"
person
Adam Fyles
schedule
01.04.2009
(+1) Я не знал о MSBuildExtensionsPath, который, согласно документации, является полезным местом для размещения настраиваемых целевых файлов. msdn.microsoft.com/en-us/library/ms164309.aspx
- person Pedro; 03.06.2009
