2009-03-02 2 views
2

Я пытаюсь настроить файл common.targets с некоторыми распространенными целями msbuild, которые я хочу использовать в своих сборках и, следовательно, импортировать в файлы TFSBuild.proj. Мне интересно, что это лучший способ достичь этого? Нужно ли мне хранить common.targets рядом с каждым файлом TFSBuild.proj и, следовательно, иметь дубликаты файла целей для каждой команды или есть другой способ? Я бы предпочел не помещать файл целей на каждую из машин сборки.Где я должен хранить общие цели для сборки команды?

+0

Здесь есть несколько хороших ответов. Почему бы вам не прокомментировать, почему они не работают или не принимают их ..... – Vaccano

+1

Вы правы. Сделано так. Спасибо за Ваш ответ. – Fadeproof

ответ

3

Team Build имеет фазу начальной загрузки перед вызовом TFSBuild.proj в котором только TFSBuild.proj и другие файлы в том же каталоге загружаются из исходного элемента управления. Так что если вы хотите, чтобы ваш файл целей, которые должны быть под контролем источника, вы должны поместить его в том же месте, как TFSBuild.proj

More details in this answer

Я никогда не пробовал, но вы можете быть в состоянии поставить файл целей на сетевом ресурсе и импортировать его с помощью share. Что-то вроде

<Import Project="\\anothermachine\share\something.targets"/> 

Но это потребовало бы, чтобы построить счет и все люди, работающие рабочий стол сборки имеют доступ к этому сетевому ресурсу.

2

Целью общего файла .targets является уменьшение дублирования ваших скриптов. Если у вас есть несколько копий этого файла под контролем источника, что происходит, когда вам нужно их менять (возможно, для обновления пути .exe)? Лично я предпочитаю отдельное место для общих файлов, которые могут ссылаться на все/все другие скрипты сборки. Единственным недостатком этого является то, что вы, вероятно, будете жестко кодировать путь к этому файлу.

2

Вы можете сохранить их рядом с объектами MS в $ Volume \ Program Files \ MSBuild. Преимущество этого заключается в том, что вы можете создать относительный путь, используя встроенные метаданные «$ (MSBuildExtensionsPath) \ Path \ To \ Your \ Targets»

+0

(+1) Я не знал о MSBuildExtensionsPath, который, согласно документации, «является полезным местом для размещения пользовательских целевых файлов». http://msdn.microsoft.com/en-us/library/ms164309.aspx – Pedro

4

Поместите его в обычное место, которое вам нравится в управлении источником. Перед использованием целей, сделать Достаньте из файла TFSBuild.proj так:

<PropertyGroup> 
    <!--Path to the TFS Command Line (used for checkin and out)--> 
    <TxTf>&quot;C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\tf&quot;</TxTf> 

    <WorkingDirectory>C:\YourPathHere<WorkingDirectory> 
    <CustomProjTFSDir>&quot;$/YourProj/YourCustomProjPath&quot;</CustomProjTFSDir> 
</PropertyGroup> 

<Exec WorkingDirectory="$(WorkingDirectory)" 
     Command="$(TxTf) get $(CustomProjTFSDir)"/> 

Ключ к этой работы заключается в установке рабочая область для построения пользовательского агента, который указывает на ваш пользовательский материал. Этот каталог НЕ должен находиться в том же пространстве, что и ваши обычные сборки.

Вакцина

+0

Где вы поместили вызов Exec? Если я помещаю его в объект «Цель», сначала сначала выполняется попытка импорта, и он терпит неудачу. Если я попытаюсь положить его прямо под корень , я получаю сообщение об ошибке. Как я могу выполнить Get в файле перед попыткой импортировать его? – Elezar

+0

@Elezar - 5 лет назад я мог бы ответить на ваш вопрос. Я многого не делал с MS Build в течение длительного времени. Сейчас я не помню. Сожалею. – Vaccano

+0

Хорошо, я новый, это был длинный выстрел, учитывая, сколько лет этот ответ. Спасибо, что ответили! – Elezar

Смежные вопросы