Вы дали так мало информации, что я испытываю желание проголосовать, чтобы закрыть. Вместо этого я рискну угадать. Вы должны опубликовать команды на этапе пост-сборки.
Если вы не знаете, какая строка не работает, попробуйте первую, одну, удалите оставшуюся и посмотрите, пройдет ли она.
Например, у меня часто возникают проблемы на машинах XP, использующих команды XCOPY на этапах после сборки, и эти команды часто приводят к действительно странным кодам ошибок, которые я не могу диагностировать или определить значение. Поэтому, если у вас есть команда XCOPY, вы должны попробовать XCOPY внутри и вне среды сборки и посмотреть, работает ли она, например, на этом Windows XP.
Вы можете скопировать команды по мере их выполнения в их макросы, развернутые в виде вкладки «Вывод» в IDE Rad Studio, вставить их в блокнот, запустить их как командный файл и попытаться выяснить, почему они не работают на Windows XP.
Вот пример обходного решения с использованием XCOPY. Если это не сработает на XP, я подправлю его, пока он не заработает:
XCOPY SourceDir DestDir
Мне пришлось исправить это так:
XCOPY.exe SourceDir DestDir
В другом случае я обнаружил, что должен был исправить это так:
call XCOPY SourceDir DestDir
Вы также упоминаете, что просто запускаете таинственный пакетный файл и не упоминаете, что он делает. Итак, давайте посмотрим, что мы можем сделать по-другому, чтобы запустить пакетный файл с шага после сборки .... Когда я запускаю такой пакетный файл, у меня иногда возникают проблемы в XP, например:
batchfilename.cmd
Но когда я запускаю его по-другому, я вижу, что он работает на XP, но я теряю вывод командной строки:
call batchfilename.cmd
Казалось, что при выполнении шагов после сборки в IDE происходит что-то странное, что может быть решено с помощью команд вне среды IDE в различных формах.
Упомянутое вами число (20018) - это глупая вещь, чтобы поискать в Google, это, вероятно, ERRORLEVEL (возвращаемое значение в командной оболочке) любого инструмента, который вы используете в своем пакетном файле. Поскольку вы ничего не сказали нам о том, какие инструменты вы используете, мне интересно, сделали ли вы хотя бы базовый шаг, чтобы посмотреть, что происходит, когда вы запускаете этот пакетный файл ВНЕ IDE на этом компьютере с XP. Я предполагаю, что если он не пришел из вашего собственного пакетного файла, то он пришел из глубины самого MSBUILD, который очень немногие люди Delphi будут знать исходный код (даже сама команда Delphi использует двоичный файл от Microsoft для обеспечения функциональности MSBUild). Я заметил, что встроенные в MSBUILD задачи для выполнения шагов после сборки и перед сборкой являются областью среды IDE, которая нуждается в улучшении, особенно когда речь идет об устранении подобных проблем. Однако вы можете просто запустить их вне IDE и посмотреть, работают ли они таким образом, и вы можете попробовать что-то, как я предлагал выше.
Если это ваш пакетный файл ... Я полагаю, что из-за проблем с зависимостями вы можете не захотеть использовать такой метод пакетного файла для изменения файла RC, так как это может показать некоторую странную зависимость проблемы в MSBUILD с задачами сборки RAD / Delphi. Я также видел некоторые странные сбои BRCC32 в XP, которые мне не удалось воспроизвести.