2017-01-18 13 views

ответ

1

Задача реализует Task class и поэтому может быть вызвана из кода msbuild. Обычно это делается, например, написав некоторый код C#, реализующий класс, и построил его в dll, который передается элементу UsingTask, чтобы сделать его доступным. Существует также более короткий способ сделать это: используя Inline Tasks. Это позволяет записывать код directlry в файле msbuild.

В то же время нет альтернативы, поскольку задача имеет определение, приведенное выше, и существует только одна такая вещь с точно такими свойствами в msbuild. Существует также Target, хотя он используется для вызова задач (и имеет множество других функций, таких как выражение зависимостей для других целей, определение его/выходов, ...). Таким образом, это альтернатива, учитывая, что существует некоторое совпадение, и я предполагаю, что это то, о чем вы спрашиваете: вы можете создавать функциональные возможности либо путем вызова нескольких Заданий последовательно в Целевом (или цели зависят от других целей и т. Д.), Либо путем написания ваших собственная задача, которая выполняет все или некоторые из этих действий.

Пример: предположим, что вы хотите перечислить каталог и скопировать все файлы .c в другой каталог, а затем запишите каталог. Либо вы пишете Target, в котором вы указываете файлы (используя ItemGroup), а затем вызываете задания Copy и Zip. Или вы пишете настраиваемую задачу, которая использует вызовы C#, такие как Directory.GetFiles/File.Copy/ZipFile.CreateDirectory и имеет целевой вызов только для вашей пользовательской задачи.

Преимущества пользовательских задач: они могут содержать произвольный код, поэтому вы можете в принципе сделать что-нибудь вы можете себе представить. Недостаток: его нужно создавать, поддерживать и отправлять с помощью кода msbuild, используя их (либо как dll, либо как исходный код, и в этом случае они должны быть созданы на лету, прежде чем они могут быть использованы).

Преимущества целей с существующими (встроенными) задачами: наиболее распространенная функциональность, обнаруженная в системах сборки, легко доступна в проверенном и проверенном коде с достаточной документацией и/или вопросами SO в качестве дополнительных ресурсов, не изобретая колесики, другие знают этот код уже есть, отсутствие поддержки пользовательского кода. Недостаток: не все функции доступны, количество выполненных задач для достижения функциональности может быть слишком высоким или непрактичным.

Когда использовать задачи в основном отвечает два абзаца выше. Я не могу сказать вам, сколько пользовательских задач вы будете писать на практике, так как я не знаю ваши дела. Глядя на весь код msbuild, я сам (для решения смешанных проектов C/C++/C#/Python), я бы сказал, что это около 95% встроенных задач и 5% пользовательских задач. Из этих 5% больше всего из задач, написанных другими ike MSBuild Community Tasks и MSBuild Extension Pack.