У нас очень странное поведение, для которого я не могу определить основную причину.Мы используем TFS (2017.U2) для компиляции нашей устаревшей системы и пытаемся обновить нашу сборочную ферму с 2008R2 до 2016 года. Система сборки использует PowerShell (v5) для циклического перемещения по списку проектов VBP и запуска сценария VBS дляскомпилируйте проекты.
Сначала немного основ.UAC полностью отключен (в реестре, а не только в элементе управления ползунком), VB6.EXE также настроен на совместимость с XP SP3 и может запускаться от имени администратора.
К сожалению, пока мы видим VB6.EXEзапустить в диспетчере задач - он просто зависает.Ноль активности.Интерактивный запуск одной и той же компиляции прекрасно работает с одним и тем же пользователем.Это привело меня к предположению, что это была проблема среды, однако обозреватель процессов показывает мне действительную пользовательскую среду для процесса VB6.EXE.
Я не верю, что это происходит из-за ошибки VB6, как (припо крайней мере, в предыдущих версиях Windows Server), когда фоновый процесс открывает элемент пользовательского интерфейса, ОС указывает на передний план, что фон хочет взломать. Мы не видим этого.
Мы вернули это обратноПример минимального кода, который я называю «test.ps1»:
$vb6="C:\Program Files (x86)\Microsoft Visual Studio\VB98\vb6.exe"
Set-Location D:\Builds\27\s\path\prjdir
start-process $vb6 -ArgumentList "/make /out errors.txt project.vbp" -wait
Мы использовали «start-process» для запуска компиляций VB6, потому что прямой вызов через PowerShell неправильно принимает параметры (на самом деле они построены из строк, переданных в мастер-скрипт в полномасштабном процессе ... это упрощенная версия).
При интерактивном запуске (. \ test.ps1) эта функция работает правильно.Проект скомпилирован, и я получаю файл errors.txt с записью.
При запуске как процесс (start-process. \ Test.ps1) он снова работает правильно.
При запуске через TFSЗадача «PowerShell Script», при этом не удается выполнить шаг VB6 - VB6.EXE можно увидеть в средстве просмотра задач с соответствующими аргументами, и с задачей не связан ни ЦП, ни IO.Файл errors.txt не записывается.Новая библиотека DLL не создается.
Мне удалось еще больше заглушить это и удалить TFS из стека, запустив тестовый скрипт с другого компьютера.Я запустил удаленный вызов сценария и продублировал результат с помощью этой команды:
PS C:\Users\svc_build> Invoke-Command –ComputerName TestBuild02 –ScriptBlock {powershell C:\Users\svc_build\desktop\test.ps1 }
Опять же, нет ошибок .txt и нет новой DLL.VB6.EXE запускается и просто сидит там.Монитор процессов не предоставляет никакой помощи в диагностике, что может быть причиной проблемы.
Теперь пахнет защитной дверью, закрытой для меня - даже если один и тот же пользователь домена выполняет одно и то же задание, разница в том, что этофоновый процесс ... и что-то мешает фоновому процессу выполняться в том же контексте, что и процесс переднего плана.
Предполагая, что это предположение верно, кто-то может указать мне на причину, по которой удаленно запускаемый (фоновый) сеанс не может запустить VB6.EXE?(и, конечно, было бы полезно обойти эту ситуацию :))
Если это не проблема безопасности - может кто-то определить реального виновника и решение для запуска VB6 в качестве фонового процесса,как мы привыкли видеть его на W2K8R2?