The Exec task calls cmd.exe instead of directly invoking a process.

Этот таск используется для вызова утилиты ilasm.exe примерно таким образом.

Вопрос, зачем было так делать, если в статье
https://docs.microsoft.com/ru-ru/dotnet/api/microsoft.build.utilities.tooltask?view=msbuild-16-netcore
есть реализация класса

 public class ILAsm : ToolTask

который вызывает утилиту ilasm напрямую?

Я спрашиваю потому что у Microsoft плохая документация для параметра ExitCode у задачи Exec
и мне непонятно, в каких случаях происходит останов сборки:
— когда утилиты вывела что-либо в stderr (ExitCode должен стать равен -1)
— или только когда у утилиты код возврата не 0

Здравствуйте, Arsen.Shnurkov, Вы писали:

AS>Вопрос, зачем было так делать, если в статье... есть реализация класса... который вызывает утилиту ilasm напрямую?

Потому что ILAsmTask из статьи — это «a very simple and incomplete ToolTask to wrap the ILASM.EXE tool.» Просто наколеночный иллюстрирующий пример в документации.

AS>Этот таск используется для вызова утилиты ilasm.exe примерно таким образом.
AS>Я спрашиваю потому что у Microsoft плохая документация для параметра ExitCode у задачи Exec

Отличная документация:

ExitCode... Specifies the exit code that is provided by the executed command

AS>и мне непонятно, в каких случаях происходит останов сборки:

Как трактовать ExitCode у произвольной утилиты командной строки, вызываемой через Exec-таску, очевидно, должна решать вызывающая сторона, а не авторы Exec-таски. В данном случае этот код привязывается к проперте _ILAsmExitCode через элемент Output:

<Output TaskParameter="ExitCode" PropertyName="_ILAsmExitCode" />
                                               ^^^^^^^^^^^^^^

которая испльзуется дальше по тексту.

AS>- когда утилиты вывела что-либо в stderr (ExitCode должен стать равен -1)
AS>- или только когда у утилиты код возврата не 0

Вот же написано:

<Error Text="ILAsm failed" Condition="'$(_ILAsmExitCode)' != '0'" />
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^

AS>и мне непонятно, в каких случаях происходит останов сборки:

Stops a build and logs an error based on an evaluated conditional statement.
— https://docs.microsoft.com/en-us/visualstudio/msbuild/error-task?view=vs-2019

Останов сборки произойдёт, если выполнится строка

<Error Text="ILAsm failed" Condition="'$(_ILAsmExitCode)' != '0'" />

А эта строка выполнится, если выполнится её условие

'$(_ILAsmExitCode)' != '0'

А проперть _ILAsmExitCode в данном случае получает значение ExitCode команды Exec, которая в данном случае вызывает ilasm. (Имя проперти _ILAsmExitCode может быть произвольным, это просто переменная.)

Q> Отличная документация
Вот я тоже её читал.
Ещё там дальше написано:

except that if the task logged any errors, but the process had an exit code of 0 (success), ExitCode is set to -1.

То есть, если ilasm выведет что-нибудь в stderr, то ExitCode будет установлен в -1,
а сама задача будет

task returns false if the executed command returns a non-zero exit code.

(там же на этой же странице написано)

И если Task вернёт false

При сбое задачи остальные задачи в элементе Target и сборке не выполняются, и считается, что возник сбой всего элемента Target и всей сборки.

Это вот тут написано — https://docs.microsoft.com/en-us/visualstudio/msbuild/task-element-msbuild?view=vs-2019

То есть все твои проверки не будут выполнены, и всё что ты написал не будет иметь отношения к реальности.

AS>>Вопрос, зачем было так делать, если в статье... есть реализация класса... который вызывает утилиту ilasm напрямую?

Q>Потому что ILAsmTask из статьи — это «a very simple and incomplete ToolTask to wrap the ILASM.EXE tool.» Просто наколеночный иллюстрирующий пример в документации.

А вот что дядьки из Microsoft пишут на тему чем Custom Task лучше Exec:

Custom tasks that wrap up executables have many advantages to simply using
the Exec task. Some of those benefits are outlined in the following list:
— Ease of use Since custom tasks have specific properties for inputs and outputs, they
are very easy to use.
— Better input validation You can write .NET code to validate the parameters that the
script is requesting be sent to the executable.
— Easier path resolution Sometimes you may not know where the .exe file resides. You
may have to search the registry or examine a set of folders. This is typically performed
more easily in code than in an MSBuild script.
— Pre- and post-processing Because you are creating a custom task, you can perform
actions before and/or after the execution of the executable.
— Parsing stdout and stderr The ToolTask class can detect errors and warnings from
messages that are sent into the stdout and stderr streams.
— Enables task execution skipping By overriding the SkipTaskExecution method, you can
programmatically determine if the task should be skipped.

Здравствуйте, Arsen.Shnurkov, Вы писали:

Q>>Потому что ILAsmTask из статьи — это «a very simple and incomplete...»
AS>А вот что дядьки из Microsoft пишут на тему чем Custom Task лучше Exec:

Это я знаю, мне и самому приходилось реализовывать MSBuild-таски. Вопрос был про класс из статьи — а он не особо полезный. Не стоит того, чтобы как-то резолвить сторонний таск и усложнять скрипт сборки.