Блог

Я пытаюсь включить некоторую автоматизацию процесса распаковки для развертываний Autodesk. Это в основном небольшой EXE-файл, который загружает и распаковывает массивную, раздутую структуру папок развертывания. Ключевым моментом здесь является то, что Autodesk не предоставляет возможности запускать этот исполняемый файл в автоматическом режиме, и по завершении @%#$#ing EXE также выдает модальный диалог, требующий взаимодействия с пользователем. Но поскольку каждый год нам нужно выполнять МНОЖЕСТВО развертываний, в зависимости от требований к программному обеспечению фирмы, это становится хорошим кандидатом для автоматизации. EXE — файл создает окно с кнопкой без значения по умолчанию Cancel , а затем окно по завершении с одной кнопкой, Close установленной по умолчанию (т. е. выделенной). Поэтому я подумал о том, чтобы перейти в режим полного клуджа (он же типичный способ работы с Autodesk) и выполнить отправку ключей {Enter} . Однако, хотя эта Cancel кнопка не выделена, она принимает ввод, поэтому моя работа, которая следит за соответствующим процессом и отправляет ввод, отменяет распаковку. На данный момент я чувствую, что возможны еще два уровня клуджа. Безопаснее всего было бы, если бы я мог каким-то образом получить больше, чем просто заголовок окна процесса. Если бы я мог отобразить сообщение в этом окне или название кнопки, я мог бы различать два состояния и отправлять ключи только после завершения распаковки. Есть ли какой-нибудь хитрый трюк, чтобы получить больше, чем просто название окна? Другой, ГОРАЗДО более рискованный подход состоял бы в том, чтобы каким-то образом оценить, насколько активен исполняемый файл, глядя на активность процессора/диска/сети, поскольку все три должны быть равны нулю только после завершения. Но Autodesk пишет действительно плохой код, и я могу представить себе крайний случай, когда их код действительно какое-то время ничего не делает. Или, что более вероятно, он никогда на самом деле ничего не делает, даже по завершении. Тем не менее, я готов, по крайней мере, протестировать его, поэтому мне интересно, есть ли способ получить эти три показателя непосредственно из объекта процесса, или мне нужно использовать Get-CimInstance? И если да, то каков наиболее эффективный для процессора способ получить только эти три показателя? Это будет выполняться как задание с таймером в 1 секунду, поэтому оно должно быть несколько эффективным.

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